Re: GTA03 - buttons or touchscreen
My preferences, in order: 3) combination touchscreen plus qwerty 1) touchscreen (no qwerty buttons) 2) qwerty keyboard and tracker ball ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: PIM software (was: Back to the basics: improving user experience)
On Fri, 2008-10-17 at 14:02 +0200, Mark Weinem wrote: Yes, the do indeed use MySQL! The follow-up question to that is: Does it really _need_ MySQL, or does it just use the convenience of an SQL back-end? If it just needs SQL, then it could be altered to use SQLite. If it requires MySQL, then it may be more work to port to SQLite than to make something new. To me, the fact that there are so many PIM projects for Linux means two things: 1) It's fun to write one, and 2) Everyone has their own (possibly incompatible) requirements for what a PIM stack should do. I can see how it would be fun to write one, but with all the existing ones (EDS, various KDE-based ones, GPE, QTopia, etc.) I don't really want to. Plus I'm still fighting with building an OpenMoko environment (Fighting with MokoMakefile on a Fedora 8 box). But I do agree that there is a strong need for PIM functions on the phone. I also think it's something we as the community can do while leaving the Core Developers free to work on their stated projects. I would like some guidance from the folks at FreeSmartPhone.org (Since FSO is supposed to define a PIM API) but thus far it doesn't look like anything has been written about it yet. Ideally what I'd like to see is a front-end and back-end APIs for the PIM functions, so those who really like one PIM server or another (See above-mentioned ones) can plug-in whatever they like (Possibly with a shim that translates it for the FSO API). -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko apps website ?
On Tue, 2008-08-19 at 12:09 +0100, Valerio Valerio wrote: Hi, besides projects.openmoko, I think OpenMoko should have a new website more oriented to the users, it all the OpenMoko applications organized by categories, with screenshots, small descriptions and also the direct link to the packages. Something like this: http://maemo.org/downloads/OS2008/ Sometimes I go to the screenshots area of linuxtogo and I see very cool app running on the FR there, but a lot of times I don't know what app is, this new site will resolve this lack for sure. When OpenMoko goes to prime time, and non technical people get in touch it the phone this application site will give a lot of help to those people that don't know all the free apps that can install in the phone. what do you think ? I like the idea, but I think we can do it a few steps better. 1) Rather than downloading the ipkg/opkg file through the browser (Which isn't a bad idea, see 2) using some kind of URL such as opkg://install?pkg=pkgname or opkg://install?repo=extraspkg=pkgname. That way a site could have screenshots, news, changelogs, user reviews, etc. but not have to keep up with the latest rev of some of the more rapidly-developing software. 2) For packages that aren't in repos (shocking I know), opkg could have a local-install option similar to yum and dpkg that will satisfy unmet dependencies from available repositories making the downloads smaller (If it doesn't already). The ipkg/opkg file gets downloaded then passed to opkg which takes it from there. 3) Not strictly related to this problem, but one of the things that has really endeared me to yum is the ability to install/update repos with a single RPM file. No mucking around editing a .cfg file to add/remove repos, just drop a formatted .repo file in the appropriate directory and all the yum-enabled package managers start using it. (Again, assuming this isn't something opkg does already) So in conclusion, I like the idea. Something like software.openmoko.org or mokosoftware.org that has all sorts of goodies like categories, notifications, RSS feeds, a mobile front-end (maybe just a CSS target) suitable for browsing right from a Moko device, etc. Too bad the source to Freshmeat isn't available. However, I would like to see package files contain better meta-data (e.g. a decent description, a Homepage URL, and a License tag so you can determine if it's something you want to install BEFORE you commit it to your device). -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: MokSec - The Security Framework
Apologies for the tardiness of this post. On Mon, 2008-07-14 at 10:57 -0400, Crane, Matthew wrote: I would think on a phone the primary concern is protecting the user data. E.g. sms, contacts, history. If somebody was able to malicously install software on the phone, your pretty much already [EMAIL PROTECTED]'ed. Not letting it call out helps, but it's already defeated. I'm assuming we're not installing a lot of new unknowns on a secure device, and anything trying to make network connections is evol. You're forgetting a large attack vector: social engineering. It doesn't require someone being able to maliciously install something for it to get on your system, especially once Moko repositories start to flourish and organizations setup their own for specific apps/purposes. Additionally, having used several mobile phones (Smart and otherwise) often it is helpful to be able to decide what abilities a piece of downloaded software will have (e.g. a game doesn't need to look at my address book). You're also assuming that it's a secure device and that the owner will know how to keep it that way. From experience, I can tell you that as soon as non-geeks get a hold of this phone (Presumably sometime this fall) device security will go out the window. I've been picturing running an encrypted rootfs image off an SD card. There could be multiple encrypted rootfs images, only one would be the real one, or they all could be used for different reasons. Not a bad idea. I had to do something similar with my Zaurus 5500 several years ago because 14M of storage is not enough. However with the FreeRunner, I do actually want to keep my rootfs on the rootfs and use the card(s) for different data sets. Once the system boots it's up to the user to unlock the keys to the encrypted image to be used and that gets booted from the already running kernel. Then what happens if you leave the system in sleep mode and accidentally leave it somewhere and it wanders off? You've unlocked the rootfs already, so as long as the attacker doesn't reboot the phone, they've got access. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: not being able to use Skype is a big problem
On Jul 2, 2008, at 10:22 PM, Jeremiah Flerchinger wrote: hacking android to run was tried, without too much luck, as mentioned at http://benno.id.au/blog/2007/11/21/android-neo1973 Depending on how open Android is made, it, or parts of it may run on OpenMoko. I'm not holding my breath though, I'm more excited by the native software being written. Having an Android emulator or whatever gets ported may be good eventually, depending on how good the Android apps ever become. getting back to skype, i don't see why anyone would really want or need it. there are plenty of other voip clients such as ekiga. gizmo may also be an option on the freerunner. someone else was working on a voip client specifically for the FreeRunner, but I can't remember who at the moment. Most people don't want to run Skype, they just happen to run it because everyone they talk to through it uses it. They don't really care other than it makes calls cheap/free. Maybe they use Skype-in/out but from what I've seen, most don't. Personally, I prefer a normal VoIP (SIP) client, but I don't have a big group of Skype-using friends. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How Slow Is Fast?
Anyone who has paid attention to this mailing list over the last few months has seen the It doesn't have 3G, it's worthless messages about the FreeRunner. For me (And many, many others) having a fast, power-hungry wireless pipe to the phone isn't as important as everything else the FreeRunner brings to the table. But I do have a question: What kind of thru-put can we expect to see from the GPRS radio in the FreeRunner? Is it 2k/sec dial-up speed? I'm interested in any information about this radio, theoretical as well as experiential (Now that people are getting FreeRunners). I've got some grand plans in the works, which may or may not ever come to fruition, but some of the design considerations hinge on what kind of bandwidth the GPRS radio provides. Also, and I know this has been talked about before, but is the final word that the GPRS can or cannot be active at the same time as the GSM (Class B or whatever it's called)? An ongoing GPRS connection would be really nice but if it can suspend/resume decently (Something like v.92 on modems if anyone remembers those). -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Battery life case design
On Wed, 2008-07-02 at 00:04 +0200, Diego Fdez. Durán wrote: El mar, 01-07-2008 a las 13:22 -0700, steve escribió: A deeper back cover is an option. The cad files are open. I also thought of an external battery pack What about this: http://www.thinkgeek.com/gadgets/travelpower/7d34/ ? The specs says: Output power: 6.58 Volts - 320 mA (max) in direct sunlight. Can it power the FreeRunner (power no just charge) ? Personally, I'll be using a Solio Hybrid Charger (http://www.solio.com/charger/) with a Mini-USB tip and a max output of [EMAIL PROTECTED], so it should be able to put out the 500mA the Neo wants for fast charge (I know it can output 500mA because that's what the Blackberry 8830 wants and I have successfully charged one). Even the Hybrid 1000 can output 1.2A but I'm not sure it has enough capacity to fully charge a FreeRunner). -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Which image
On Wed, 2008-07-02 at 12:16 +0200, Jay Vaughan wrote: The point is - what can we *developers* target for our end users? Without some stability on this image issue, 3rd-party developers are gonna get screwed. There may well be a market for new apps on OpenMoko; but not if there is no way we developers can reliably target bundles for the phone. Depending on exactly what you need, you should be able to develop in just about anything you want. The Openmoko devs have been vocal about the normal Moko firmware having Qt, GTK+, and EFL libraries on it, as well as at LEAST Python as a scripting language (I'm sure there will be more, though I don't know exactly which ones will be stock). If your application needs telephone facilities, or to communicate with the specialized hardware on a FreeRunner or other Moko device, you should target the FSO D-Bus specs (Though those are still in flux). As long as your software is packaged in the OPKG format (Like all Moko software should be), then you should be able to add a Dependency on just about any other package provided in an OpenMoko directory (Though if you're targeting the widest audience, you should probably stick to the main repo(s)). -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Let us impact the material world
On Sat, 2008-06-28 at 12:24 -0500, Nelson Castillo wrote: Doesn't IM requiere permanent connection? For status updates, etc? Not necessarily. A lot of us used IM back in the old dial-up days. I've done a lot of thinking on this subject over the last several years and tried several systems with my existing phone and GPRS connection. If the IM protocol in use (I'm thinking XMPP) supports offline storage, distributed servers, and connection encryption, and preferably a robust message delivery system (e.g. requiring an ack for messages sent) then it should be usable, provided the phone has a data connection. It could/would shorten battery runtime keeping the GPRS up all the time, but a lot of that depends on other power-saving in the device. If the user has very limited data connection (e.g. only WWW (Port 80), and MAIL (Ports 25, 110, 143, 587, 993) then a proxy of some kind would be necessary. The proxy would need to maintain the user's login to the IM network and provide storage of messages sent by the client program (running on the phone). For those with no data connections, something involving SMS (And eventually MMS if/when it's ever ported) would need to be created. A lot of provider IM programs (At least the ones I've used) rely on SMS to transport messages to/from the phone. I'd like to know what you think about two things: 1) We know email is broken (at least unsafe and prone to spam) 2) What is the best alternative for this scenario? Is it really IM? 3) Are there other (IP-based) protocolos suitable for delivering the encrypted messages? Honestly, for the usage pattern I reckon most people will use (based on my existing usage of SMS and the various people who I correspond with), SMS is just phone-based IM, so extending real IM to the phone, especially with an extensible format like XMPP can be a real boon. E-mail is still (IMHO) a bit heavy (More than 1k in headers to deliver a one-line message). I don't remember right now if XMPP provides for a compressed transport, but I do know that by default it encrypts the connection. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Let us impact the material world
On Sat, 2008-06-28 at 20:54 +0800, xiangfu wrote: may be can use SMS control the remote NEO like send #neo_command shutdown -h now then the neo poweroff : ) Something like this has been floating around the mailing list for months (or more) now. Personally, I'm hoping that the SMS stack in FSO will allow plugins to filter incoming SMS messages and provide a secure(ish) functionality for something like this. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth Headset compatible to Freerunner?
On Tue, 2008-07-01 at 15:07 +0200, kenneth marken wrote: try this then: http://www.sonyericsson.com/cws/products/accessories/overview/hbh-ds205?cc=gblc=en Does anyone have one of these, or has anyone used one? If this has a mic (for the headset/handsfree profile) and can stream decent sound in the AD2P profile, and do headset things like last-number-redial, then it will be the first accessory I buy for the FreeRunner. I've got a pair of Sony canal-phones that would go perfectly with this. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth Headset compatible to Freerunner?
On Tue, 2008-07-01 at 15:11 +0200, kenneth marken wrote: i think its as sonyerricson only feature or something. its the same thing they use on their watches: http://www.sonyericsson.com/cws/products/accessories/overview/mbw-150classicedition?cc=gblc=en where if its paired up with a recent sonyericsson phone, it can display the number (or name if stored in the phones contacts) of whoever is calling. i dont recall this being part of the official bluetooth spec at any point... Even in the Handsfree profile? I'm not a Bluetooth guru (Barely started using it, actually) but aren't the Headset and Handsfree profiles different, with the latter being able to do more and some exotic things like displaying CallerID info and such? -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTK on FSO (was: Community Initiative GTK)
As a long-time Linux user, I have an emotional attachment to GTK+ that ... um ... transcends reason. And primarily for that reason, I would like to see the old GTK+ interfaces (often called GTK software stack or 2007.2 stack) maintained. I will even be helping where and how I can (Though I can't make solid commitments). After reading a lot on the Community and Devel mailing lists, it seems like the primary thing that needs to be done (At this point) is for the GTK Dialer and Preferences (and things like SMS handling, SIM access, and others) to be ported to the FreeSmartphone.Org (FSO) framework, which basically entails ripping out the guts of those programs and replacing them with a bunch of DBus calls to the existing (And future) FSO daemons (Parts of the E17/EFL/QtX11 ASU will require similar work if it hasn't been completed yet). Thus far, it looks like FSO primarily defines a Device API (getting/setting device settings, triggering/waking-from suspend, etc), an Event API (Not yet documented), a Usage API (not yet documented), a Preferences API (Profiles and such), and a Telephony API (This is the spec that's received the most work to-date) which includes things like call handling, SMS, GSM network information and operations, and SIM-card access. It looks like their Wiki has stubs for higher-level things like PIM, networking, Bluetooth, audio, etc. and I am eager to see what they come up with for these, as that spec will permeate the entire mobile software stack. However, I predict (I'm going out on a limb here) that these will be very difficult subjects to target and will require extensive work (just PIM is an area with several books' worth of discussion and disagreement). Honestly, once FSO stabilizes, it should be easy to write GTK, QT, EFL, Curses, etc interfaces for the phone systems as all you need is a DBus connection. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: moko running everything as root
On Mon, 2008-06-16 at 14:41 -0400, Kevin Dean wrote: You dispute that the user data is the most important part of the mobile device experience? No one (that I've seen thus far) is arguing that the user data is not the most irreplaceable (and to the user, important) part of a mobile device. What most everyone seems to be arguing is that running EVERYTHING as root for convenience is opening us up to a world of possibilities, all of them bad. My previous e-mail has been clear - I WANT security on the device. However, I simply don't beleive that the root/user seperation is the most important consideration in that regard. You tossed out some great security ideas, onces I'd personally put time into doing on my own device, but with all due respect, you're saying my statements are nonsense and then offering solutions that (while they work) aren't what I was saying. Protecting user data is key so encryption and a built-in, fully automated backup system is somethign I think would be a GREAT thing to have. But it doesn't refute my point at all - a non-root user can destroy the most critical part of the system and doesn't need root to do it. Implimenting a root/user seperation itself doesn't mitigate this risk. I agree that this risk needs to be mitigated, I simply don't believe that the root/user split does much to lessen the risks. The root/user separation is the most fundamental part of a security policy and here is why. Root is by its nature not only unrestricted but unrestrictable (I think I just made up a new word). A non-root user can only destroy the data that user owns. Now while the conventional desktop, user johndoe owns all his MP3s and pr0n and thus can delete and otherwise destroy them; on the Moko platform, the extensive use of DBus makes destruction of the most important part more difficult. What I'm saying is that (Where possible) a daemon holds the important data (PIM data, calendar data, etc) and is capable of restricting what the user can do with it. The user account communicates with this daemon (via DBus or whatever) and gets the data the user wants while protecting the same. Both being normal users, they are not allowed to step on each other, but if the user is root, then someone with malicious intents can exploit that user account to step on the guardian account, either causing a DoS (crash) or actually manipulating/destroying data. I guess what I'm actually saying is that moving from an unrestricted account (root) to a restricted account (user) won't automagically buy us protection from all data-loss possibilities, but the mindset of moving to a normal user account is a core principle of a real security architecture. Ideally, something like an SELinux policy would be able to restrict capabilities without requiring different user accounts to do it (e.g. anything running as browser_r cannot talk to anything running as sms_r even though they're the same user). And if you're worried about deleting random data, a fairly simple chown/chmod will protect against that. That stuff doesn't work if the user you're guarding against is root. That's correct if the data is encrypted but encryption isn't what's being tossed around here. If all your data is stored in the clear, and an intruder has physical access to the device, the distinctions between root and non-root user don't matter. That's what I'm saying. That also depends on how long the malicious user has physical access and how fast the malicious user works. If the malicious user has only a few minutes and isn't proficient in cracking OM devices, the changes of damage are less. If the user can't keep good physical control of the device, then yes, they'll get pwn3d eventually, but no one I know of is that careless with their phones anymore. Even the non-geeky don't let their phones out of their sight for more than a few minutes. Now I'm not saying that such careless users don't exist, just that physical access and the root/user differentiation are not the same problem, and one should not override the other. Encryption is another matter, and one I will want addressed before too long. I've got some ideas on how it can be done, but I'll need to see more of the OM system live before I can begin to decide if my ideas are feasible or if they need changing. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Utah Group buy?
On Thu, 2008-04-24 at 14:54 -0600, Travis Tabbal wrote: Are there enough of us in Utah to bother? Maybe I can join the Denver group if not. :) Since there have been almost no replies, I'm guessing not, though this should probably be circulated around local LUG lists to see if extra interest can be located. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 850MHz or 900MHz? ATT or TMobile?
On Sun, 2008-03-23 at 00:50 -0700, Lowell Higley wrote: I bought a tri-band phone while I lived in Europe. It is 900Mhz/1900Mhz. I had no problems with it on T-Mobile's USA network while I was their customer. I tend to buy my phones is Asia or Europe because they are unlocked and usually not crippled. T-Mobile in particular likes to artificially limit their phones. For example, they will limit SMS messages to say 30 characters when that is not the technological limit. My theory is they do this to increase the number text messages sent so they can get you to buy a more expensive SMS plan or charge you the 10 cents per message overage charge. Sounds like you got a raw deal. I'd have quit too if my T-mobile experience was like that. I've been a T-mobile customer since they were VoiceStream and I've had no problems. I stopped buying phones from T-Mo directly many years ago (Back when consumer phones were switching from B/W to color) and instead I have bought my last couple of phones from eBay, unlocked. I've had no problems using them with my SIM card. T-Mo's website doesn't recognize my phone when I login, but I know a compatible model (Same OS, same QWERTY keyboard) so I override it and everything mostly works for me (Some of their T-Zones website features don't seem to want to work, but I stopped caring about those when I found free equivalents online). I'm anxious to try GPRS on a FreeRunner. I hope the 2.5G will be faster and more capable than the radio that's in my current phone. I've never seen T-mo artificially limit phones; not like I've seen Verizon do it. All my texts have been sent as 160-chars-per and my phone automatically reassembles the ones that get split, so any 30-char limit isn't a feature of the network. I haven't actually had to call T-mo customer service in several years. I get signal pretty much everywhere I want it and where I don't, there's generally a localized reason that everyone else is subject to. -KW ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An idea of sorts
On Sat, 2007-07-28 at 15:36 +0100, Giles Jones wrote: ipkg is based on dpkg, it's more lightweight. It's also a bit more than just a dpkg clone, since it includes repositories and such. Don't get me wrong, we need package management, it's just that I've owned Windows Mobile phones and there's been no easy way to install software when using Linux. Getting a reliable sync solution that works on Windows, Mac OS and Linux is quite a big piece of work and while this is in development it is handy to have an alternative. ipkg-install (package) isn't easy enough, or a GUI front-end to the same? As for sync, since this IS a totally Open project, I'm sure there will be different alternatives, maybe even one for Linux, one for Mac, and one for Windows. It may also be that there are packages required on the PC side to complete the sync (Some kind of plugin for ActiveSync and iSync that talks SyncML, or a new profile for iSync for the Moko maybe). I'm also wondering how we are going to achieve installing applications on the SD card, have a lib directory and bin directory on there and add these to the paths? If they base it on ipkg, the way other OpenEmbedded platforms work, when you insert the card, the OS will check for and add any applications that are installed on the SD to the program manager. It's a little more involved than just adding a lib/bin directory to the respective path, but it worked well before my Zaurus died. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: email vs forum
On Wed, Jul 25, 2007 at 03:39:08PM +0200, ramsesoriginal wrote: nice. And now explain this to your Grandmother. Because as Einstein said: you have only understood something whe you can explain it to your grandmother. For you it's easy to say that you simply have to use IMAP, but the average consumer that only needs to knoe the answer to his question probably isn't going to learn how to set it up. I don't know what kind of grandmother you have, but not even my mother would participate in either an OpenMoko mailing list or a forum. If your grandmother is anything like mine, the first time she has an issue or a question, she will call me (you) and you will have to find the answer. And the average user of an OpenMoKo phone (At least at this stage in the game) is going to have to setup e-mail anyway. If the e-mail reader on the platform is any good, it will be able to handle multiple accounts and filter incoming/outgoing messages anyway. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Replying to digests Was: Re: community Digest, Vol 36, Issue 48
On Thu, Jul 19, 2007 at 05:44:29PM -0400, Jon Radel wrote: [Entire digest that has nothing at all to do with the above that both you sent out again removed.] Spam the whole mailing list? Ah, at least you're forthright and know yourself well... Ever occur to you two forum fans that the mailing list would work better if you used it right? Little matters such as: * If you're starting a new discussion thread, don't reply to an existing e-mail; it throws off the people who use thread-aware MUAs. * If you're replying to something in a digest cut out all the stuff you're not replying to and fix up the subject line. * TRIM! * TRIM SOME MORE! * If you're sending a Me Too reply, TRIM YET SOME MORE! (See Mathew Davis's follow up for a beautiful example of trimming. :-) I agree. My main problem with a forum is that all the ones I've have serious deficiencies, the biggest one being that it's really easy to lose new messages if you don't dedicate a block of time to reading all new messages (Sometimes in just one forum, sometimes site-wide). I have yet to see a forum software that doesn't mark them all read if you have an emergency in the middle and have to come back later. For some people that's fine, but I prefer that my e-mail box stores a flag in each message and lets me read on my own time. As for the rest, I concur. Good netiquette goes a long way. Too bad it's a dying art. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: adding data services with t.mobile for neo 1973
On Sun, 2007-07-01 at 09:40 -0700, Brian Beattie wrote: I'm thinking about getting an openmoko phone and I have service with t.mobile. Searching the t,mobile web page does not tell me how to add data service to my plan since they think, there are no internet plans compatible with my device. Does anybody here know how I would go about adding data service to my plan without buying a device I don't need? I too have T-Mobile and I am currently using an unsupported device. As much of a pain as it will be, I'd say your best bet is to call them and have one of their customer service people add whatever you're after to your plan. That's what I'll likely do when I get my Neo (Either in a month or three months, depending on finances). You can either call 611 from your phone or call their 800 number from another phone (I've had to do it both ways for various reasons). -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
On Thu, 2007-06-07 at 01:23 +0200, Michael 'Mickey' Lauer wrote: ... GameBoy provided nice full-screen animations in 1989, eighteen years ago. This is nothing like the GameBoy, or the C64, or the Amiga. The GB was a single-tasking system that would always only be doing one thing at a time. The C64 was as well. The Amiga had no memory protection so one errant program could bring down the whole OS. No one would go for that now. A Neo or any OpenMoKo phone will have to coordinate a lot of programs and several windows at a time; programs that may have come from repos that aren't as tight on the QA as others, so the OS (and the windowing system) has to be able to protect itself. I'm 100% sure nobody will cry after pure-X11 applications we loose this way. Almost every GTK application would require rewriting/porting to fit OpenMoko capabilities, so it's not great loss too. Not to mention font and other DPI-aware issues. And you'd be 100% wrong in at least a few occasions. X11 applications aren't just for running desktop apps on the Moko. They can also be for running Moko apps on the desktop. I mean, personally, if I'm home and I want to look up a phone number while I'm sitting at my computer, I don't necessarily want to drag the phone out of my pocket, unlock the screen, then bring up the contacts screen and search for my target when I can just: ssh -CY mymoko mymoko contacts And it comes up on my 22 LCD, where I can cut and paste from an e-mail or whatever and have it instantly on my phone. No file copying or data replication required. Yes, I know I could just sync that stuff across, but for anything that doesn't have syncing built in, it would be really nice for me to be able to just bring up the app and interact with it without dragging the phone out of my pocket or my coat in another room. There were so many times my Zaurus was on the charger, with the CF Wifi card in it and I would have loved to bring up one of the Z apps but couldn't. Now, I realize I'm in the minority of this minority, but I run X11 apps across the network ALL THE TIME. I even installed X11 on my Mac so I could do it there too. As for porting, there are lots of programs I would like to see on the Moko and most of them are GTK-based already (For one, I'd like to see Gobby on a Moko for collaborative note taking during meetings). It would also be interesting to be able to run apps from one MoKo and control them on another MoKo across a Bluetooth or Wifi network (With appropriate security precautions, of course). Interesting. Can I hear more supportive or counter arguments? What do the others think? First, I get a sad little chill when people think that dropping X11 will solve all their speed problems, with absolutely no knowledge of X11's origins and progress over the last several decades. Yeah it's another layer of indirection, but over the years X.org (formerly XFree86) has implemented various methods for speeding up the rendering path that require no changes in the application code. DRI is one of them, MIT-SHM is another. It's gotten to the point where running a pure-X11 application is waiting on me, not the other way around. And this is on old hardware (Pentium 3 450) across the Internet. Dropping X11 means that we need to find something to replace it, and that something (DirectFB or whatever) will need to implement enough functionality that we're not stuck when some buggy app goes out and locks up the GUI because it's holding a token (or equivalent) and everything else is deadlocked (Which I saw entirely too often on my Zaurus). In addition, this lightweight replacement needs to be faster as well as at least as robust and documented. What I'm curious about is if the GUI has received any love or even attention at this point. The Core Team has repeatedly stated that they're working at the lower levels of the OS (Kernel, modules, drivers, daemons, etc), which makes me think the GUI stack hasn't been run through any profiling or debugging. Hell, it could still have all debugging symbols turned on, which won't be the case in the finished product. Also, the fact that the GTA_01 doesn't have any graphical acceleration will also make the GUI run slowly compared to what people are used to. Even the most bargain basement PC has a 2D accelerator in it. In fact, I haven't seen any that don't have a 3D accelerator in them anymore. For a PDA with a 320x240 screen, pushing pixels is 1/4 as hard as on a real VGA screen. Yeah, we pay a price for the glorious screen on the Neo, but from what we've all been hearing about the GTA_02, that will hopefully not be a problem. Yeah, I like X11 and I like GTK. I like their functionality, their maturity, and their licenses. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
On Fri, Apr 06, 2007 at 10:31:47AM -0700, Tim Newsom wrote: 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. There are two kinds of delivery reports, because I've specifically got them turned off in my phone, but my sister still gets them when she sends to me, so I think they're network-generated, and that means they will only work as far as the network can tell, so if transferring to a different network (She's on a different one than I am), she'll only know when they're sent to my network, not to me. And I know my phone doesn't send them back, because she has received some when I was out of coverage. 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? It may depend on the phone, but on my current phone yes, SMS can be sent and received while I'm on a call. I've had that happen MANY times, and my phone isn't one of the ones that can GSM and GPRS at the same time. 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. Assuming that the receipts are sent from the phone, yes, there should be. However, if (as I suspect) they are generated by the network, there's nothing you can do about them, but they're not terribly accurate to begin with. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, Mar 20, 2007 at 03:06:18PM +, Jim McDonald wrote: 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. I agree, to an extent. I've used a lot of security programs on a lot of handhelds and I would like something that's sort of a cross between the way Palm OS does security and the way GNOME does security. On PalmOS, each record has a private flag that can be set. In the OS, there is a setting for what to do with private records, either hide them, redact them (black them out in listings) or show them. If we could combine this with a system daemon that keeps the encryption key in memory for a user-selectable amount of time (1 minute, 5 minutes, until sleep, etc), then it would minimize the annoyance factor of having to type in your password all the time while still having a per-item level of security. A system encryption engine would also allow the user to select their level of security (light vs. strong) and possibly be extended to keep multiple keys/encryption schemes. For anything beyond that, it may have to be implemented through plugins or as a stand-alone encrypted message application (a.la CryptoPad on Palm or ZSafe on Zaurus). 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... A wise man once said something to the effect of: make it as simple as possible, but no simpler. Some things may need to be more than a check-box, but I doubt things will end up needlessly complex. I think to avoid ugly interfaces, we will need to make things somewhat abstracted and flexible. That way if v1 is rather ugly, then v2 could be made better without overhauling the entire thing. And the interface should be kept separate from the implementation, so one can be updated without breaking the other. Probably something that talks through DBus to a storage engine of some kind. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 2007-03-18 at 12:19 +, Jim McDonald wrote: Or perhaps some sort of voice recognition, perhaps a user-chosen phrase? 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). -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 2007-03-18 at 18:57 +0100, Paul Wouters wrote: 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 wouldn't. Brute-forcing a passphrase/pin is only as simple as the passphrase/pin. Plus you are limiting your thinking to the current MoKo platform (The Neo). In the future there may be MoKo devices with hardware keyboards and without touch screens. An entropy meter associated with the creation of the passphrase/pin would be very useful, as would having a high limit on the number of characters, or no limit at all. It could help people choose better passphrases, making the people more security conscious in the process. Almost all of my passwords are 15+ characters, but they are all memorable (to me) and when I've run them through stand-alone entropy meters, they all rate very highly. 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. Yes, lots of variables, like fuzzy-matching the symbol, because I don't know about you, but I don't think I can be pixel-perfect drawing on a touchscreen in any reasonable length of time. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Voice Activated Controls
On Mon, Feb 26, 2007 at 05:08:18PM -0600, Jonathon Suggs wrote: Does anyone know of any software for natural language processing that could be ported to OM/Neo? I really like some of the software that is available for the PocketPC (MS Voice Commander and Fonix). They both run and work well on a resource limited platform as well, so it *can* be done, but both are closed. Here are a couple of OS engines: http://www.speech.cs.cmu.edu/pocketsphinx/ http://julius.sourceforge.jp/en_index.php?q=en/index.html http://xvoice.sourceforge.net/ So I guess, is there already any voice control software planned/worked on for use in OpenMoko? If not, I'll help out, but can we get a project up and running? Depending on what you're looking for, it may be easier than that. My last three phones (All Nokia) have a speech command recognition which seems more like limited wave-form matching. It requires that I record the command (Call Brian, Start music player, Begin recording) then when I want to use that command, I hold down a button on the phone (Or on the headset) until the phone makes a certain tone, and speak the command. The phone then searches for a few seconds, finds the match, and activates the function. It's VERY useful for when I'm driving and want to call someone. I just hold down a button on my headset and give it the command, all while keeping my eyes on the road. My only major complaint is the (very) limited number of commands you can record. I find I have to think really hard about what I want a voice command for because making a new one requires that I remove an existing one. It wouldn't give you continuous speech-to-text capability, but I'm not sure I want that. People think I'm crazy enough as it is. -KW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Idea: Caller set ringtone
On Tue, Feb 13, 2007 at 04:13:43PM +, Ole Tange wrote: Caller should be able to transfer and set his ring tone. If the phone displays a picture when the phone is ringing, then caller should be able to transfer and set this as well. No phone I've seen yet allows the caller to set anything on the callee's phone, and I can imagine several reasons why I wouldn't really want this on a MoKo phone, though I can imagine several reasons why I would as well. The transfer of the ring tone should preferably be done, when calling. But if that is not feasible then it should be done the next time the phone is connected to a cheap communication channel (internet). This will depend on a few things, namely if the phone supports GSM and GPRS connections at the same time, if the provider supports those, and if the caller and callee have data plans. To avoid abuse the callee should be able to deny people from doing it. Default would be deny. Actually, a better idea I can see is having some kind of a P2P (Phone to phone) application running on the MoKo that allows people to beam items between phones easily. That way when I'm near a friend who has a MoKo, (s)he could send me their personalized ring tone and even picture and then I could associate those with their contact record so they'd come up when that person calls. In fact, beaming (preferably with a minimum of effort on the users' part) entire contact records would be really nice as well. That way when someone asks for my number, I can just send them my business card and they'll have all the information I want to share. Or I could get a family member's contact information from another family member through the same mechanism. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile finagling advice?
On Tue, Feb 06, 2007 at 06:25:30PM -0700, Ben Burdette wrote: So, I'm thinking seriously about getting a neo1973 when they become available. I called the local T Mobile office and asked them whether I could borrow a phone to see how the signal strength is where I live. They said I could get a 14 day trial with a free phone and just take it back when that is over. That would probably be the best way to test a phone, as even their street- by-street coverage maps aren't 100% accurate (But to be fair, ther street map of my house shows I have less signal than I actually do). This is, of course if you live in the US. I don't know if their coverage map works in Europe. My question is, has anyone been through this process before, what's the best way to find out how the service is? I don't know anyone that has a t mobile phone (maybe that should tell me something). And the other thing is, how would I get the neo1973 onto the t mobile network? would I have to get their cheapest phone and then remove the sim card to use in the neo1973? Is it possible to get the sim card without buying a t mobile phone? I know that you can go to t-mobile.com and click the Coverage link in the bar at the top, then punch in your address and it should show you. Other than that, just trying to get a T-Mo phone and try it. Like you said earlier, you can try it for 14 days. As for the getting a Neo on the T-Mo network, that will be easy for basic things and harder for others. Currently, I use a non-T-Mo phone on my T-mo account, and when my girlfriend joined up, she got the same phone from eBay and we got the SIM card from the local T-Mo store. Technically, she got their free phone and they just gave us the card out of it. It didn't cost us anything. I'm sure I could find out more by calling T Mobile, but I'm betting there's a lot of expertise in this area on this list. Also, another thing to consider is that Cingular (The New ATT) uses GSM networks for mobile phones as well, so if T-Mo isn't cutting it for you, and if Cingular is in your area, you can look into them as well. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
On Thu, Feb 01, 2007 at 08:48:15AM -0600, Jonathon Suggs wrote: That sounds very interesting. I very much like the concept and look forward to seeing how it is implemented. Although it is an overall travesty, Windows Mobile has a single messaging program that you can configure all of your different inboxes in (SMS, MMS, POP, IMAP, etc) but they are all separate entities. When sending, you still have to choose which account you are sending from (but that is not a bad thing IMHO). After reading this e-mail list, it seems to me that no one here wants a different inbox or handler interface for each type of message (I know it annoys me), so having something that unifies all text-based communications protocols would be a good idea. And from what I've seen, on other phone platforms, unless they're trying to up-sell you on particular communications mediums (e.g. e-mail is an add-on), they like to keep their messaging in one app. As for sending messages, I would think it would only need to prompt you when you're sending a new message (Maybe in the recipient lookup window, when you select a recipient, it displays all the ways it knows of to send the message to that person and you pick one). If you're replying to an existing message, it should be able to discern what communications channel to use based on the one that the incoming message arrived through (I know some e-mail clients do this now; replying with the e-mail address the original sender used, so long as it is configured as an account in the program). But personally, I would like an option to switch a reply to a different communication channel (e.g. switch to MMS if receiver supports it and I don't want my message split every 160 chars; or switch to e-mail or IM if I have that capability on the phone/plan and the appropriate contact info listed for the recipient), but for most users, just replying on the same channel that the message came in on would be sufficient. On the other hand, I see some very big hurdles. First, you would have to know a lot (not really, but just follow) about your contact as SMS, IM and email are different protocols owned/managed by different entities (SMS/MMS=carrier, IM=aim,yahoo,google,etc, email=email provider). Also, this messaging client would have to know how to talk over all of the IM protocols, SMS/MMS (has standards, but different carriers sometimes do different things), and email (pretty standard protocol, so no biggie). As someone pointed out to me this morning, half of that is taken care of, though it may still require some adaption. There is a FreeDesktop.org project called Telepathy (telepathy.freedesktop.org) which aims provide a unified framework for all forms of real time conversations, including instant messaging, IRC, voice calls and video calls. It uses DBus to provide that framework, and back-ends to talk to each communications channel. It is at least theoretically possible to write an SMS and/or MMS module, and possibly an e-mail module to provide the back-haul communications. This isn't to say that it can't be done, and I'm sure that it has all been thought through, but it ain't going to be easy to get people (especially carriers) to work with you. Agreed, which is why I would make the OpenMoKo messaging program as flexible as possible, so as to provide as much choice to the user and accomodate the carriers as much as possible (be a good sport). Not overly worried, but it is easy to get caught up in the excitement. I've seen quite a few posts about ideas that evolve around everyone all having a Neo... And that just isn't going to happen (especially in the near term). Just thought I would give a quick reality check. Neither am I, as at the end of the day, this IS an Open Source project, so anything can be changed if necessary, but (Like a lot of other people on this mailing list, I imagine), I want things to be designed RIGHT, so as to minimize the number of re-writes we have to go through before we get something that can work for the wide variety of people who WILL have a MoKo. Yes, if/when we get to a situation where there are a lot of MoKo devices running around, it can open a lot more possibilities, but there is no way in the foreseeable future that I will be able to get most of the people who are important to me to buy a Neo (Either because they're not on a GSM network and don't want to switch, or they don't want to pay that much for a phone). Getting the mobile industry to be a more open environment for everyone is a great idea and one that I support, but as they say Rome wasn't built in a day. In general, mobile carriers are some of the biggest control freaks, so needless to say, they aren't going to welcome these type of projects with open arms. As do I, but I see this as more difficult than trying to convince my family to switch carriers. As it is, even with a phone that is entirely supported by my carrier's network (But not purchased from them),
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
On Wed, 2007-01-31 at 22:48 -0700, Richi Plana wrote: I, personally, do not use MMS. I'm not even sure if that service is available here in Calgary, AB with the carriers here. I've had a dinky, free phone since the start waiting for the right phone (this one) to come along. However, we should also keep in mind that which the majority of phones out there support, and right now (at least in Europe according to the research mentioned above), it seems to be MMS. I remember when I first got SMS on my phone way back in the day. No one seemed to care. But several years later, it actually made the news when some networks announced inter-network interoperability in the MMS arena, after it became rather obvious that people like shooting grainy, low-resolution camera phone pics and instantly sending them to their friends. Personally, I would rather use MMS for its ability to send up to 1000 characters per message, rather than the paltry 160 of SMS (And my network charges me per-message, not per-byte for either). Maybe I just write too much, but sometimes my phone breaks up a message into 3 (or more) SMS messages and it gets really aggravating if it coughs in the middle and fails to send because something went wrong with part 2 or 3. One approach we could use is to have the application layer (the GUI as seen by the user) designed right, and the underlying protocol would be the one to differ. So a user can compose some multimedia message and it could be sent out as MMS (possibly with a loss of formatting due to constraints in MMS). This would be a smart way to get users used to our application frontend so that when we switch to that better infrastructure you're dreaming of, it would make no difference to the users. They'll just notice that things have just gotten better. Once the current MMS users who've bought into OpenMoko have had a taste of what we can offer, they wouldn't want to go back. But we have to hook them in the first place. That was basically my thought as well. I would like to see is an integrated Messaging application that is capable of integrating all available messaging back-ends in one place and lets the user (Or the content or recipient address if it comes to that) decide the method to send the message. I believe some other phones do something like this already. But then again, I would also like to be able to store messaging preferences in the Contacts list, so I can do things like send specially-encoded messages to other MoKo owners (with things like formatting, encryption, etc) and send regular SMS or MMS messages to those unfortunate souls who have not yet joined us. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Silent mode timeout
On Mon, Jan 29, 2007 at 09:30:38AM -0700, Ben Burdette wrote: A simple feature that I'd like to see is a silent mode timeout. What always happens with my current phone is I set it to silent mode because I'm in a movie or a meeting, and then later I forget to turn the ringer back on. This leads to a lot of missed calls. You could have a default timeout for simply holding down the 'volume down' button (if there is one on this phone), and this default would initially be 'no timeout'. When you enter silent mode, the GUI could display this current timeout and allow you to adjust it then. A checkbox would allow you to make this the new default timeout. I agree with this, but not just for silent mode. My current phone (Nokia) has the ability to set a timed expiration (profile expires at a specified time and returns to the previous profile) for ALL phone profiles. It's EXTREMELY useful, as I can set it to Meeting mode at the beginning of a meeting and have it automatically return to Normal mode at the end of the meeting, though with the MoKo's GPS ability, I'd also like to see if it's possible to set profiles to expire if I've traveled a set distance from the current position (e.g. 50 meters to cover possible GPS inaccuracies). -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Possibilities for commercial software?
On Thu, 2007-01-25 at 22:04 +0100, Ortwin Regel wrote: I like open source and stuff but some things, especially games, are closed in many cases. What are the possibilities for selling closed software for OpenMoko devices? Will there be a central online marketplace? What about DRM, is there a way to bind a program to a sync ID like it's usually done with PalmOS or to a device ID? (It should be possible to bind it to an SD card ID, right?) Any creative ideas how to solve the usual issues people have with stupid DRM systems etc. and still being able to get money for software development? There are as many possibilities for selling closed software on the OpenMoKo platform as there are on any other device; probably more, since the SDK doesn't cost a mint for a developer license. As for DRM, it is my honest opinion that it is entirely wrong-headed and causes more harm than good, and I would be very surprised if anyone implements it on this platform. I know that when (not if) I buy one, I will absolutely not allow any of that crap on my hardware. But I'm not averse to buying software, including games, especially if it's good. As for getting money for software development, people were doing that long before DRM was the gleam in a corporate monopolist's eye. Again, it is my honest opinion that one can make money selling software for the OpenMoKo, but it will probably require time, patience, and talent. and passion for your work. If your software is good, reasonably priced, and easily attainable, you should be able to make some money. Make it easier to buy the software from you than to pirate it and you should do alright. While I can't speak for the company, I'm sure there will be tons of on-line software clearinghouses for OpenMoKo software. If the company doesn't create one, someone else will, and if you're serious about selling software on the OpenMoKo platform, you'll have it listed on all of them. Personally, I'm really excited about this phone, even though it doesn't have everything my heart desires, and I've already been working on ideas for enhancements to existing (proposed) software as well as new software. However I'm not planning on trying to make any money off of it, and will be releasing it under a Free license. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Required Software
On Fri, 2007-01-26 at 10:16 -0700, Richi Plana wrote: I've been working with Linux for such a long time and I'm not sure what that VPN client is. Truth is, though most popular network devices (Cisco, etc.) use VPN that Linux supports, it's Microsoft's VPN system that's most prevalent in the companies I've encountered. Does anyone know which VPN system works with MS? The choices for Linux I'm aware of are Open/FreeSWAN (IPSec), Cisco VPN 5000 client, PPTP VPN and OpenVPN (SSL-based). There's one I've heard of called PopTop that is supposed to work with Microsoft's PPTP VPN system. As for Cisco, there is the VPN client, but I don't like compiling their modules into my kernel. The one I use with the Ciscos at work is called vpnc ( http://www.unix-ag.uni-kl.de/~massar/vpnc/ ) and it works well, only requiring the tun/tap driver in the kernel. OpenVPN, while it's my favorite, is only compatible with itself. Security is very important to roaming devices which have to go through public infrastructures like the Internet. I agree, which is why my OpenMoKo will probably have vpnc and OpenVPN on it. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
