Re: idea for Neo 2nd generation: Accelerometer
On 1/31/07, kkr [EMAIL PROTECTED] wrote: Another exemple of uses for an accelerometer: magnifier command set (enable only in the context of a picture viewer or web browser application). Look at http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/3DViewport /Ole ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Openess of OpenMoko's Hardware
Hi everyone, seems like the mailing list is slowly taking off, having much more messages now than couple of months ago! Great stuff!! I was wondering how far OpenMoko itself is tied to the underlying hardware? OpenMoko gives us a great new way to write purely native software on an open platform. But how about hardware? During talks I had with my collegues and friends (non-geeks included), it seems that looks of the hardware is an important criteria when buying a phone. Some like it slim, some like bars, some others flip phones, some again prefer sliding phones. So the question arises in how far other companies could pick up the OpenMoko platform and port it for another hardware. Is the project obliged to FIC in any way? I mean the core developer is being paid by them! Let's say I love the OpenMoko idea, but would like the phone itself to look nicer. What could I do? (Maybe Sean can give us some ideas what it takes to build the phone hardware and convince me that it's pretty impossible for a normal person or a small business to do so?) Vinh ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
2-3 flavours ; ) Re: the power of defaults Re: Any alternative ideas to fullscreen popup-messages?
Salve Bryan,Mickey,*! IMHO an important usergroup for OpenMoko/Neo1973 (in the beginning) will be *nix administrators, developers and maintainers. A comfortable ssh client will makes their smartphone to a mobile terminal - that the device is trustworthy is very important... They are used to use Linux without GUI or with spartanic GUI and they are used that the tools behave very predictable - a vim window will not be suddendy overlapped by a popup window. Mickey wrote it is still just a phone - well, for me is the mobil shell, mobil (emebedded) linux computing more important than that the Neo1973 is a phone. I like it, that i can phone with it and I also like to contribute ideas/solution to make phoning more confortable: that not everybody is bothering me in just the moment when *he* wants to talk with me, while I'm - eating - learning - paying in a shop - changing the train - I'm writing an SMS/Email And I'm not thinking to swith off the phone or just rejecting the incomming calls as alternative - I serveral cases just 2-10 seconds would be perfect to finish something that I'm would doing with my Neo as PDA or mobil computer/shell I just want the comfort when I have PDA and GSM phone as two seperate devices. And I do not care about the need to have one step more to answer a call, when I would work with a PDA I would have also 2 steps 1. get the phone into my hand 2. answer the call With OpenMoko 1. swith to telephone mode/screen (with a keystroke for the austere/Spartan lovers, one icon as compromise (LED for the future would be interesting :))) 2. answer the call While not using the Neo as PDA/mobil computer/mobil shell it will behave just like a Phone, one step to pick up the call. On Wed, 31 Jan 2007, Bryan Fink wrote: On 1/31/07, Andrew Turner [EMAIL PROTECTED] wrote: My preference would be some system whereby I could select a list of events that are allowed to interrupt me, and to what level they're allowed to interrupt - visual: fullscreen/halfscreen/footer/none; audio: interrupt/mix over/none. This seems like too much work to setup profiles/configurations etc. Most users probably wouldn't bother. Very important to consider The Power of Defaults :) See Flickr and default Public on photos vs. private by all the other photo sites. A *very* good point. I fell into the typical developer trap of casting myself as an average user there for a minute. Hell, now that I think about it further, even I'd get tired of switching options and settle on some, probably less than optimal, default. :P So when OpenMoko have 2-3 flavors like -OpenMoko Normal (with bothering instant popups like every other smartphone) -OpenMoko austere/Spartan/Guru/Admin/Expert/ It would be ease to develope with just 2-3 different flavors. Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
[moved to community mailinglist]Re: ruby in openmoko
Salve Fred! Welcome to the OpenMoko community. :) On Thu, 01 Feb 2007, [EMAIL PROTECTED] wrote: Hi All, I am new to this mailing list. I have not seen any email mentioning Ruby and Rails. Can anyone please forward old emails relating to ruby in openmoko? please use google with site:openmoko.org ruby I am a newbie to ruby. But heard that ruby is a programming language that can make life of a programmer a little bit comfortable. That's why I am starting to learn it. When somebody makes a packet for ruby, it will be possible to install ruby with OpenMoko - AFAIK is this not done yet and I can imagine that ruby will be not installed by default (But I'm just a listmember and not memeber of the core developing team). Of course ruby is a language with a great potential, but consider that the Neo1973 is still an embedded device with limited recources. So a concentration on some used languages will save recources and will make cooperation more easy. Developing and learning with OpenMoko could be more fruitfull when using languages which are used with OpenMoko regulary. That I moved with your mail to the other list is not personal, every idea or questions seems to deal with development, so on the first view you have choosen the right mailinglist. But what for what does we need then the community mailinglist? We have a second development list to make it people who are working on a concret programming project with OpenMoko more easy to start - to find informations... So a general question will be xy comming with OpenMoko is a community question ;) And don't get me wrong, on a long term (next months) it would be very fine to have the power to use ruby with OpenMoko, that people having good programs/skripts with ruby could also use them with OpenMoko. With google you will find some talk about ruby on the community mailinglist, and when the first Neos are shipped, I think some of the first users will play/use Ruby so that then it will be more to read/discuss. Maybe some other ruby interested people on this community list? (community list is older and has much more members) Beside Ruby you are also welcome to share your ideas/whishes about an open Linux Smartphone ;) Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
Salve denis! denis schrieb am Donnerstag, den 01. Februar 2007 um 11:03h: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) One of the most important things, from my point of view, talking abount a mobile phone is the possibility to get a silent alarm with the help of a LED. A binking screen should be visibel enough. So is something like this planed? We collected some ideas for the next version of the Neo and having one or more LEDs are already an idea/wish discussed here. Greetings rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: [moved to community mailinglist]Re: ruby in openmoko
Dnia czwartek, 1 lutego 2007 11:43, Robert Michel napisał: On Thu, 01 Feb 2007, [EMAIL PROTECTED] wrote: I am new to this mailing list. I have not seen any email mentioning Ruby and Rails. I am a newbie to ruby. But heard that ruby is a programming language that can make life of a programmer a little bit comfortable. That's why I am starting to learn it. When somebody makes a packet for ruby, it will be possible to install ruby with OpenMoko - AFAIK is this not done yet and I can imagine that ruby will be not installed by default (But I'm just a listmember and not memeber of the core developing team). Ruby 1.8.5 is in OpenEmbedded so it will probably be available in proper feeds so user will be able to install it. -- JID: hrw-jabber.org OpenEmbedded developer/consultant A person who aims at nothing is sure to hit it. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
But for many reasons it is important to start whith an working device now (I don't want to restart a discussion about this, just as an explanaitions for Denis) and the Neo1973 will be much much more than I have dreamed about a hackable Linux phone for a long time! I understand that! Let us be happy what all we can do with the first version ;) I will definetly be happy with that version. ;) Because the shipping of the first version is very soon, it is now not the pefect time for hardware ideas for next generations, but to give you a feedback that your idea will not got lost I started a new page on our (temorary) wiki: http://www.linuxtogo.org/gowiki/OpenMoko/Hardware_wishes_for_next_versions But this LEDs are not soo important that you prefer to wait utill 2008 instead of getting the first hackable Linux phone in March - or? ;) For sure I will not wait for the phone till 2008. I'm so interested in the possibilties you have with such a phone so I can't wait any longer. Regards, Denis -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Michel Gesendet: Donnerstag, 1. Februar 2007 12:41 An: community@lists.openmoko.org Betreff: Re: Posibility to get status informations with the help of a LED Salve denis! denis schrieb am Donnerstag, den 01. Februar 2007 um 12:17h: Salve rob! :) It's great that an implementation of LEDs is discussed. use google site:openmoko.org LED My problem with flashing screens is the high amount of energy that it costs. At the moment I have a SE S700i and I always have to turn the screen on in order to get to know if there are messages or emails. And blinking only two or three times is not enought because you're not looking at the screen all the time. Flashing LEDs have the advantage that they cost less energy and can blink over a large amount of time. So you just look at the LED and know ah there is a sms or ah I got an email. yes :) In my opinion it's not much effort to integrate a LED into the hardware and it gives you a lot of options for telling the user something about the status of its phone. Consider that the first devices will be send out in the next days, so I would love to see a postponing of the release for adding some more nice hardware feature to the Neo, like flashing LEDs But for many reasons it is important to start whith an working device now (I don't want to restart a discussion about this, just as an explanaitions for Denis) and the Neo1973 will be much much more than I have dreamed about a hackable Linux phone for a long time! Let us be happy what all we can do with the first version ;) Because the shipping of the first version is very soon, it is now not the pefect time for hardware ideas for next generations, but to give you a feedback that your idea will not got lost I started a new page on our (temorary) wiki: http://www.linuxtogo.org/gowiki/OpenMoko/Hardware_wishes_for_next_versions But this LEDs are not soo important that you prefer to wait utill 2008 instead of getting the first hackable Linux phone in March - or? ;) Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: [moved to community mailinglist]Re: ruby in openmoko
On 2/1/07, Marcin Juszkiewicz [EMAIL PROTECTED] wrote: I am a newbie to ruby. But heard that ruby is a programming language that can make life of a programmer a little bit comfortable. That's why I am starting to learn it. Ruby 1.8.5 is in OpenEmbedded so it will probably be available in proper feeds so user will be able to install it. To make Ruby useful, it would need some bindings to GTK and possibly Neo hardware components. This would, of course, be very cool :) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
11 Lanuages :) Re: Wikipedia update
Salve Sergio! On Thu, 01 Feb 2007, Sergio Bessa wrote: OpenMoko in Portuguese http://pt.wikipedia.org/wiki/OpenMoko Great! I have also seen that we have a finish version new as well! Was it your work, Janni-Matti? So that makes 11 languages now :))) Hey this is fun and shows how powerfull our community already is - 11 languages strong! [[da:OpenMoko]] [[de:OpenMoko]] [[en:OpenMoko]] [[es:OpenMoko]] [[fi:OpenMoko]] [[fr:OpenMoko]] [[it:Openmoko]] [[nl:OpenMoko]] [[pl:OpenMoko]] [[pt:OpenMoko]] [[ru:OpenMoko]] So it is easy to join and spend some minutes for translating, and when someone finds some mistakes in any languages don't blame the translator - just be productive and fix it yourself! Any ideas how to make the english article better? And that OpenMoko will be found by Wikipedia users, we can gives OpenMoko some links inside the wikipedia for every languages at pages that makes sence like: WhatLinkshere http://en.wikipedia.org/wiki/Special:Whatlinkshere/OpenMoko * Symbian OS * Smartphone * Embedded Linux * Open source hardware * List of smartphones * TuxPhone * Openmoko (redirect page) * Neo1973 (redirect page) Mentioned on Symbion OS page? See: http://en.wikipedia.org/wiki/Symbian_OS Maby this is not a neutral way to link OpenMoko, IMHO it is better to have less links from other articles but un-disputed. BTW Whats the role of OpenEmbedded for OpenMoko? So suggestion: let us first make the linking of the english version better, and then use this linking ideas for other languages. A list which is growin as well is: http://www.linuxtogo.org/gowiki/OpenMoko/Translation :) At last the list of translated wikipedia articles could grow with (Afrikaans),Hebrew,(Japanese) and Turkish. This OpenMoko project makes much fun ;) Cheers, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Any alternative ideas to fullscreen popup-messages?
Michael 'Mickey' Lauer skrev: Let's distinguish two types of popup-dialogs: a) informative (i.e. battery low, incoming sms, sms sent) b) confirmative (Mickey calling. Answer / Ignore / Reject?, Do you want to remove all contacts?) Right now, we're leaning towards (ab)using the bottom status bar (in openmoko-language called 'footer') for informative dialogs and using half screen (480x320) popup dialogs for confirmative. Let's distinguish asynchronous and synchronous popup. Do you want to remove all contacts? is probably synchronous, a direct reply to a users actions. Then a floating modal popup is OK. But it should be slightly less then half screen and movable - so You can inspect the screen before answering. Avoiding one gui annoyance. For asynchronous popup, like incoming phone call, The footer notification aria is better. Along with the notification area could be a 'popup' botton showing more info and buttons for actions in a 'popup' aria sliding up from the footer. The aria should have short history (2 min?) navigation for when allot of notifications comes in fast. That is enough for most stuff (like incoming sms). No button pop up over user action unless the user ask to. Phone call *are* special on a phone :-) There should be one tap to answer the phone, and always in the same easy to find position. So, put the notification area in one side of the footer, the general popup button on the side facing away from the corner. When there is an incoming call, use the notification aria as usual, but put an 'answer' button in the corner end of the aria bar. The corner is easy locatable, it is a corner normally covered by the notification area so no user interaction should ever go there. And newer ever use that space for any other interaction! Games will want to brake this... So... give them an option to move the footer to the top of the screen (more rarely used fore game input)? Buttons to cancel the call should be on the popup like normal, together with all info on the caller. Wasting the complete footer for notifications sound expensive, but have the advantage that popup button also ends up in a corner. But I bet a keyboard button and a few more is more important. BTW: I'm not completely against phone call popup to popup automatically, but then any buttons in the popup must be disabled for 1/2 a second. Actually, it's not *too* bad having preferences for what event that should auto popup and not. Harder problem... What to do when the screen is off and a phone call comes in? Turning the screen on is OK, but I don't want the touch-interface to go on in my pocket... so what to do that's not completely awkward. See little choice but to use the 'hardware' buttons. But there position do not look optimal. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
On Wed, 2007-01-31 at 16:14 -0800, Elliot F. wrote: The best point that Robert made in his original post was that there are out of band methods of alerting the phone that a new message is available (call from known number or SMS message.) As far as I know, this is how current push email systems work. I agree. Any potential method of notification should be explored since different carriers bill different features at different rates. I'm not sure what you mean by IMAP is an asynchronous protocol, By that I mean that answers / notifications from an IMAP server do not have to be returned in the order in which you send them. IE, if you make 3 requests the protocol allows the results from those requests to return in any arbitrary order plus of course the possibility of additional notifications which you don't explicitly request. but I never said that IDLE was a poll. I did not intend to infer that. I was wanting to clarify what I read to be slightly ambiguous. It's also not there JUST to spot the IMAP server tearing down the connection. I typoed. s/spot/stop/ It's there to stop the IMAP server closing the connection as IDLE. I'd prefer they used NOOP but I didn't author the protocol :-P IMAP IDLE is 'true' push email (at least the earliest I know of.) IMAP maintains a persistent connection to a server (see my comment above re: pushing data is easy with a persistent connection.) The server can then push messages via the established connection. For those interested: http://www.faqs.org/rfcs/rfc2177.html Absolutely. My whole point is that maintaining a persistent connection between the mobile phone is (in my opinion) not efficient, not as easy, and more prone to error than using some sort of out-of-band notification. Well, the IDLE interval required is going to be dependent on the IMAP server and carrier (you can be sure they time-out idle tcp sessions through their NAT gateways). Whether it is efficient or not on this platform is a financial choice. For example, I have unlimited data on my plan but I am charged per SMS (Cingular USA). SMS would be expensive for me as a notification mechanism. As for initializing calls, I saw a company abuse ISDN bandwidth that way by encoding within ISDN signalling. A fully functional but low bandwidth connection without a single phonecall made. I'd be happy to see all implementations, though. There's not reason why it needs to be done just one way. Depending on the user, it may make more sense to do it one way over the other. I agreee 100%. I think I'll leave this thread now, as it doesn't seem to be bearing much fruit. I look forward to the SDK and the phone, though, as this is a very promising feature (as anyone who is a blackberry addict can attest.) Later. Red ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
One general wish - let us make encryption as easy then possible!
Salve Sean! paranoid on Sean Moss-Pultz schrieb am Donnerstag, den 01. Februar 2007 um 19:28h: Well, you're not wrong, certainly: people use MMS even though it _is_ horribly broken (and expensive, etc.) I guess the point I'm attempting to make here is that in addition to the challenges in just getting a working phone out the door, you sign up to take on what seems, to me, anyway, to be a pretty substantial educational exercise. Agreed. But we're trying our best to discourage the common user until phase 2 of our roadmap. This will give us time to see if this educational exercise produces something better than MMS. Both fingers are crossed ;-) It doesn't matter if it is about SMS,(MMS),instant messaging (jabber?),email, phonecalls or data connections (sftp/https/ssh/freenx/...) I would like to see a good security/encryption/keyhandling/OTP support as core function in the OpenMoko design. OpenMoko/Neo1973 has so much potential to achieve both - a high level of security *and* usability. E.g. the device modus of USB allows that the Neo1973 is a virtual cryptocard that protects your private key when you are working with a workstation/server... Meeting people would a great chance to exchange public keys and sign them. Non OpenMoko users you could give a J2ME applet and 140 KB random data (SMS has 160*7 Bit = 140*8 Bit) as OTP for your next 1000 SMS For companies would it be interesting to hide even the information which employee is communicate with whom - e.g. every 15 minutes every employee upload and download a dummy packet with or without information inside. Can't understand companies trusting blackberry by giving them all their sensible communication on blackberry servers. Greetings, rob PS: It is not a question if you are paronoid, it's a question if you are paranoid enough ;) ___ 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
I think a good Jabber client could totally supplant MMS - it support file transfers, which is all MMS really does (I think), as well as things MMS never dreamed of like encryption and presence and etc. Putting a good mobile-UI on, say, Psi or one of the other open source Jabber clients shouldn't be too difficult. Unless there's already one that I don't know about? Another feature could actually be an SMS-to-Jabber gateway that runs on your phone, so as long as your phone has power (and permission to get on the net, etc) your SMSs will get gatewayed to Jabber so you don't miss them if you happen to leave your phone at home. --pj On Thursday, Feb 1, 2007, Sean Moss-Pultz writes: On 2/1/07 4:30 AM, David Schlesinger [EMAIL PROTECTED] wrote: Also, who uses MMS? Only pretty much the majority of actual cellphone users in Europe, based on the market research and carrier requirements I've read... IMHO, only because nobody has given us anything better. We're trying to do that. So I asked the guys to ignore MMS for the now. If this is an issue I'll put resources on this in the future. Right now, I'd much prefer to see solutions that use GPRS such an IM / Email / ... Seems like the typical user would just email and attach media and/or just s/ftp Typical _Linux_ user, maybe. This is the sort of thing which (in my view) represents something of a disconnect between the goals of having as open a phone as possible and selling a lot of phones... You might be right. But I personally feel that MMS is fundamentally flawed. Costs aside, it's just not the way I think media should be transferred. The benefits are just too low for the end user. We're trying to fix this. Really guys, we're trying to rethink lots of things with OpenMoko. I don't want to do the same things just running under FOSS. We'd be missing out on a huge invitation to innovate both as a company and a community. Why not use the flexibility and rethink how we want these devices to work -- as end users -- not just for geeks but for everyone? I'm not saying we'll get things right the first time. Just that we're going to try our best ;-) _This_ opportunity is what makes me excited about OpenMoko. Not (simply) the fact that it's FOSS based. -Sean ___ 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: data encryption + Biometric security
Salve Ben! First it sounds a very smart idea to have biometric security, but sorry, when I give you some sceptical feedback. On Thu, 01 Feb 2007, Ben Burdette wrote: Here are a couple of items for the phone wish list: data encryption and biometric security. Biometric security wasn't discussed by the OpenMoko community yet, I'm no crypto expert, but I'm not convinced that biometric worth the hardware... see: http://www.ccc.de/biometrie/fingerabdruck_kopieren When somebody wants to play with biometric security the Neo1973 could be used for voiceanalysing - Print 7 random words to the screen and the user has to read them aloud ... I'd like the phone to be a secure place for me to store passwords and similar information. Are there plans to have some security features like this, that would prevent someone from extracting secure data from the phone if it was lost? A file could have an encrypted filesystem, acess is given only for a while and only while GPRS connection is on. If it is lost, use Internet or an asterisk server to unmount this file. Having a fingerprint scanner would be more of a convenience feature so I wouldn't have to enter a password whenever I want use the phone, or alternatively when I want to access encrypted data. Sounds nice, but I have doubts that a fingerscanner is given real security. I will going to play with my (Debian) Crytoflex card, but not to make access more easy - to make it more secure. So when I have to lost both - my Neo and my Cryptotoken. projectblackdog.com costs 199US$+Chiping for me to expensive. But this is just my 2cents When somebody has such a finger scanner and likes to make it running with OpenMoko would be fine - but expect also some feedback that the fingerscanner concept is not so secure as it looks like: google finger scanner site:www.schneier.com Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: data encryption + Biometric security
On Thu, 2007-02-01 at 10:32 -0700, Knight Walker wrote: http://www.projectblackdog.com/ Yeah. Too bad that company is going under. :) I actually have two of these and I love them. I lost faith in the company and they lost my support because I have yet to see them announce their competition winner. It's almost 2 years after the competition completed. Red ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: data encryption + Biometric security
Unfortunately I couldn't provide 100% open source on the driver or the application libraries. -Original Message- From: Dean Collins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 1:42 PM To: Heilpern, Mark; community@lists.openmoko.org Subject: RE: data encryption + Biometric security Lol, Mark, want to send a device in for evaluation to the guys. I'm sure they would be up for it. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Heilpern, Mark Sent: Thursday, 1 February 2007 1:13 PM To: community@lists.openmoko.org Subject: RE: data encryption + Biometric security There are many competing technologies behind fingerprint scanning and evaluation techniques, some which are rather weak and others which are quite strong. Forming opinions based on tests against a small subset of them is not exactly doing due dilligence. Watching things like tv's MythBusters defeat fingerprint sensors is interesting and entertaining, but when you know they're using several year old, out-dated technology for the sensors they evaluate, you might suspect that there's more to the story that they're telling you. Disclaimer: I work for a fingerprint sensor manufacturer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Michel Sent: Thursday, February 01, 2007 12:41 PM To: community@lists.openmoko.org Subject: Re: data encryption + Biometric security Salve Ben! First it sounds a very smart idea to have biometric security, but sorry, when I give you some sceptical feedback. On Thu, 01 Feb 2007, Ben Burdette wrote: Here are a couple of items for the phone wish list: data encryption and biometric security. Biometric security wasn't discussed by the OpenMoko community yet, I'm no crypto expert, but I'm not convinced that biometric worth the hardware... see: http://www.ccc.de/biometrie/fingerabdruck_kopieren When somebody wants to play with biometric security the Neo1973 could be used for voiceanalysing - Print 7 random words to the screen and the user has to read them aloud ... I'd like the phone to be a secure place for me to store passwords and similar information. Are there plans to have some security features like this, that would prevent someone from extracting secure data from the phone if it was lost? A file could have an encrypted filesystem, acess is given only for a while and only while GPRS connection is on. If it is lost, use Internet or an asterisk server to unmount this file. Having a fingerprint scanner would be more of a convenience feature so I wouldn't have to enter a password whenever I want use the phone, or alternatively when I want to access encrypted data. Sounds nice, but I have doubts that a fingerscanner is given real security. I will going to play with my (Debian) Crytoflex card, but not to make access more easy - to make it more secure. So when I have to lost both - my Neo and my Cryptotoken. projectblackdog.com costs 199US$+Chiping for me to expensive. But this is just my 2cents When somebody has such a finger scanner and likes to make it running with OpenMoko would be fine - but expect also some feedback that the fingerscanner concept is not so secure as it looks like: google finger scanner site:www.schneier.com Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: data encryption + Biometric security
No I meant to the MythBuster guys. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Heilpern, Mark Sent: Thursday, 1 February 2007 1:46 PM To: community@lists.openmoko.org Subject: RE: data encryption + Biometric security Unfortunately I couldn't provide 100% open source on the driver or the application libraries. -Original Message- From: Dean Collins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 1:42 PM To: Heilpern, Mark; community@lists.openmoko.org Subject: RE: data encryption + Biometric security Lol, Mark, want to send a device in for evaluation to the guys. I'm sure they would be up for it. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Heilpern, Mark Sent: Thursday, 1 February 2007 1:13 PM To: community@lists.openmoko.org Subject: RE: data encryption + Biometric security There are many competing technologies behind fingerprint scanning and evaluation techniques, some which are rather weak and others which are quite strong. Forming opinions based on tests against a small subset of them is not exactly doing due dilligence. Watching things like tv's MythBusters defeat fingerprint sensors is interesting and entertaining, but when you know they're using several year old, out-dated technology for the sensors they evaluate, you might suspect that there's more to the story that they're telling you. Disclaimer: I work for a fingerprint sensor manufacturer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Michel Sent: Thursday, February 01, 2007 12:41 PM To: community@lists.openmoko.org Subject: Re: data encryption + Biometric security Salve Ben! First it sounds a very smart idea to have biometric security, but sorry, when I give you some sceptical feedback. On Thu, 01 Feb 2007, Ben Burdette wrote: Here are a couple of items for the phone wish list: data encryption and biometric security. Biometric security wasn't discussed by the OpenMoko community yet, I'm no crypto expert, but I'm not convinced that biometric worth the hardware... see: http://www.ccc.de/biometrie/fingerabdruck_kopieren When somebody wants to play with biometric security the Neo1973 could be used for voiceanalysing - Print 7 random words to the screen and the user has to read them aloud ... I'd like the phone to be a secure place for me to store passwords and similar information. Are there plans to have some security features like this, that would prevent someone from extracting secure data from the phone if it was lost? A file could have an encrypted filesystem, acess is given only for a while and only while GPRS connection is on. If it is lost, use Internet or an asterisk server to unmount this file. Having a fingerprint scanner would be more of a convenience feature so I wouldn't have to enter a password whenever I want use the phone, or alternatively when I want to access encrypted data. Sounds nice, but I have doubts that a fingerscanner is given real security. I will going to play with my (Debian) Crytoflex card, but not to make access more easy - to make it more secure. So when I have to lost both - my Neo and my Cryptotoken. projectblackdog.com costs 199US$+Chiping for me to expensive. But this is just my 2cents When somebody has such a finger scanner and likes to make it running with OpenMoko would be fine - but expect also some feedback that the fingerscanner concept is not so secure as it looks like: google finger scanner site:www.schneier.com Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Wish list: Call Forwarding from Neo
Hey it is finally February :) Just wondering if call forwarding from the Neo to another phone would be a possibility or desired. Sorry if this has been discussed, but could not find it in the threads. I can set up my voip service to forward calls to my cell (or any or multiple numbers). Because my home phone calls are less expensive than my cell calls...when I am at home, I would like my cell phone calls to ring over to my home phone. It would be good if the cell phone could be programed to ring first. I do not like to tell people, who call me on my cell to call me back on my home phone, or to ask them to hang up to let me call them back. At least this, until I get a Neo with voip and I use it as my ONLY phone! In talking to friends and family about OpenMoko have found they are interested in the idea of being able to personalize their phonejust need to get them to switch to GMS after those darn contracts expire. huuum... a good reason for the GMS services to consider adding the Neo to their line. I enjoy reading all the posts (even tho much is over my head). I keep learning. Best Regard, Mary ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Wish list: Call Forwarding from Neo
2007/2/1, Mary Stovel [EMAIL PROTECTED]: Just wondering if call forwarding from the Neo to another phone would be a possibility or desired. GSM network hadles it itself, if phone lack of redirection settings, you can dial magic code like *21*number# (i don't know if it's standarized) and it just works. But you pay for every redirected call like you were calling. Of course Neo would enable and disable forwarding automatically, but remember the costs of redirected calls. -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Any alternative ideas to fullscreen popup-messages?
On 2007-02-01 22:09, Lars Hallberg wrote: Harder problem... What to do when the screen is off and a phone call comes in? Turning the screen on is OK, but I don't want the touch-interface to go on in my pocket... so what to do that's not completely awkward. See little choice but to use the 'hardware' buttons. But there position do not look optimal. The screen should definitely turn on and perhaps flash or change brightness continuously (i.e. pulse). With regards to accidental clicks, I have a couple of ideas: * Two taps at opposite corners or opposite edges to unlock. * A quick left/right/left triple tap or left-right-left drag action in the middle of the screen. * Apple's iPhone has a slide to unlock. A continuous left to right action over a certain region unlocks the phone. Since the display isn't pressure sensitive I think any of these options would probably work. Can we have all of them? :) Jason ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Sink oullook calender?
Will I be able to sink my outlook calender at work to an openmoko phone or would this only work on some form of windows mobile phone? -- Cathal O'Brien ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Wish list: Call Forwarding from Neo
Salve Mary! On Thu, 01 Feb 2007, Mary Stovel wrote: I can set up my voip service to forward calls to my cell (or any or multiple numbers). Because my home phone calls are less expensive than my cell calls...when I am at home, I would like my cell phone calls to ring over to my home phone. It would be good if the cell phone could be programed to ring first. I do not like to tell people, who call me on my cell to call me back on my home phone, or to ask them to hang up to let me call them back. At least this, until I get a Neo with voip and I use it as my ONLY phone! Asterisk PBX will help to do this: http://en.wikipedia.org/wiki/Asterisk When you have more than 256 Kb/s up and downstream you could have e.g. a NSLU2 at home to let asterisk running - or, I do have a Linux vserver for 3 Euro/Month. Asterisk is a telephonyserver which can work with SIP and also with ISDN cards Let me explain, what I use already: I have a Voip with a land line number with is cheap for my friends to call - just like normal land line numbers. My asterisk forward this call to my VoIP ATA (Greandstream HandyTone 286, will be replaced with a AVM Fritz Box) and my GSM mobil. When I'm at home I can pick up the call (without costs for me), when I pick up the call with my GSM mobil, I pay less then when my friends would call me from their land line... With the Neo1973 some improvements become possible 1. probably it is possible to forward the call via Bluetooth 2. via GPRS can I transmitt the caller id to the GSM 3. when I'm at my parents place I can switch asterisk to forward my incoming calls to my parents place. When a incoming call is comming an asterisk script will inform my Neo is ringing and a Infoscreen (mayby Popup :) says: Mary is calling forwarded to your Parents line So I can say before my parents phone ring - next call is for me ... and pick up the call The same when I visit my friends who use VoIP, then I can forward the call free of costs. With AGPS I can automatisated this forwarding. Asterik can play an intro when sombody picks up the call at my parents place This is a call for robert When you doing something like this with your office or somewhere else - Asterisk can ask you for a Code This is a call for Robert, please enter your code I will write more about these scenarious in about two weeks when I have more time. Consider that some of this ideas needs some development.. but the Neo1973 has a high potential to do nice things... To answer your subject in a short way: The best solution for forwarding calls would on a server, not on the Neo itself. So not forwarding *from* Neo, forwarding *to* the Neo. Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: data encryption + Biometric security
Salve Mark! On Thu, 01 Feb 2007, Heilpern, Mark wrote: Watching things like tv's MythBusters defeat fingerprint sensors is interesting and entertaining, but when you know they're using several year old, out-dated technology for the sensors they evaluate, you might suspect that there's more to the story that they're telling you. The German Chaos Computer Club ccc.de is not a TV program, that are quite good hackers - and also Bruce Schneier is. Rodolphe gave allready a good feedback that lake of information does not creats trust. E.G. the team of the GPG-crypto-card had to sign a NDA - so I do not trust this cards that - the algorithm didn't get extention - that the random generator is good enough - that this cards didn't have a backdoor - that the encryption result doesn't have hidden the private key inside. I wrote I'm no crypto expert - but that does not mean that I have my knowledge from the TV. BTW I trust several years old CPU and network chips more than modern chips. Disclaimer: I work for a fingerprint sensor manufacturer. I doe very welcome that people of fingerprint sensor manufactures are active here on this list. I'm just a normal member on this list (btw a civil engineering student with some ICT interest) I'm not speaking for more than for myself. I will not negate that finger sensors could be interesting, but security is not just a quetion of products and money you spent into - the slogan you always get what you paid for is definitve wrong for security. For secure systems it is relevant good when everybody understand how it is working - e.g. voting box and paper votings are IMHO more secure then voting PC could be... So the question is for what is the fingerprint sensor used on the phone 1.) avoiding calls on your bill 2.) secure your adressbook 3.) secure your private keys For 1. and 2. a fingerprint sensor brings more comfort and would be IMHO OK. But about 3 IMHO we are talking about a field - where simple and open solutions would be better - and security is more important then comfort. Let us assume I would become maintainer of some OpenMoko packets and my private key to sign would be on my Neo1973 - I hope it will be so trustworthy that this would not be seen as negligent/careless how could a fingerprinter enhanced the security for this private key? Don't get me wrong, there are many fields where not as much security as possible would be neccessary and a Neo1973 with build in fingerscanner could become a very interesting product, e.g. when somebody has employees which he could/will trust less then your company authentec.com So I do see a perspective for next generation Neos or Third party modificated Neos with buildin fingerscanners - so playing with external scanners to have some prototypes would help starting this market field - and I personal would like to see individuell modification of OpenMoko and the Neo1973 - train ticket device with printer - barcodescanner for logistic task - fingerscanner for... So yes this topic is interesting for some markets. I don't think that for normal skilled linux user a fingerprint sensor could be a full replacement of his password protection - I only would use it __only__ as additional feature, __not__ as password replacement (for real secure task like protecting private keys). Ok let us speak Tachels - the calculation of the iphone has become publish and the AGPS chip producer GlobalLocate had published in his presentation that when buying more than 10k chips the AGPS costs less then 5 US-$. Can you tell us more about your products and which level of security would be possible with costs of 5 US-$ or less. Again, I'm just a student interested in this project and I would like to compare the cost and benefit of additional components for further Neo modells. ;) But beside my direct question, I would like see this discussion going on, not only the next days - experiances with OpenMoko and more information about fingerprint sensors could build a basis that it will continous in weeks or month - so please stay active here ;) Ah, and what you are thinking about the potential of multitouch screen sensors, could they be used for a fingersensor? This would have the advantage that no additional sensor field must be in/on the device. Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea: second SIM card support
Myk Melez wrote: I'll add my thoughts to the wiki once it's back up (it seems to be down, or at least I can't reach it at the moment). Ok, I've added them to this page: http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/DualSIMCardSupport -myk ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Openmoko podcast
Hi, i didn't see this podcast mentioned here yet: http://www.lugradio.org/episodes/70 Lugradio have a typically disrespectful Openmoko (Yoko-Ono, Open-boner) review, and an interview with Mickey Lauer. I also never realized that FIC is not just some little startup, but actually the company originally behind HTC. That makes it a lot more likely that they will still be around for V2 to get released, and for V1 to actually work. Good stuff. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko podcast
I also never realized that FIC is not just some little startup That makes it a lot more likely that they will still be around for V2 to get released, and for V1 to actually work. I'm kind of surprised that FIC means so little to a lot of people I'm talking. FIC was well-known to be a manufacturer of solid x86 motherboards back in the 80s. Perhaps most people weren't into computers back those days? ;) -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko podcast
Richard Bennett wrote: Busy doing night time coding to get our phone ready? That's the spirit! ;o) Hehe, not quite, sorry. Actually I just came back from a concert and I need some time getting into sleep-mode ;) -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko podcast
Thanks Richard for the link. It is great hearing Mickey talking about the OpenMoko...very cool! ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko podcast
Michael 'Mickey' Lauer writes: I also never realized that FIC is not just some little startup That makes it a lot more likely that they will still be around for V2 to get released, and for V1 to actually work. I'm kind of surprised that FIC means so little to a lot of people I'm talking. FIC was well-known to be a manufacturer of solid x86 motherboards back in the 80s. Perhaps most people weren't into computers back those days? ;) Back then, a computer was a VAX. I have to confess, I can't remember ever having heard of the company before hearing about openmoko. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: h.264 format is now open?
Yeah, for management. Actual Video decoding is done by a dedicated chip, Broadcom BCM2722. Good find. I guess i should have just checked wikipedia instead of googling would have gotten me much better information. I will however still bet $50 (first taker actually gets payout) that there will be a way to play video on the phone. I'm betting xvid or Theora however i'm not ruling out H.264 as of yet. Don't get me wrong cpu will be pegged above 90 but with some optomizations and dedication it'll happen. Infact i'm curious to get gstreamer up and try the Fluendo codecs as they have run better than all i've found except libmad which is just amazing (IMO obviously). But hey if i'm wrong i'm wrong and someone gets 50 american dollars. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Tinymail on it?
On Thu, 2007-02-01 at 01:56 +0100, Philip Van Hoof wrote: I already asked it to some internal E-mail address, the reaction back then was positive but no real certainties. Is there interest from the OpenMoko team for bringing tinymail to the device? (http://tinymail.org) I've been reading the discussions about push e-mail, and that idea is all nice and stuff. But you'll still need an actual client to display the e-mails themselves. Philip, this would be great. You should hop over toe the openmoko-devel mailing list to discuss more. There is discussion about an integrating messaging app. Tinymail is great, uses evolution data server, and could hopefully be adapted to the openmoko platform. Nevertheless am I of course interested in whatever the final decision on push E-mail will be. I read how people where suggesting to use the newer IMAP IDLE capability for this. I would like to point out, however, that not yet all IMAP servers support this. Nevertheless is support for IDLE being planned in tinymail. (Condstore, STARTTLS and Binary are already implemented by the way). I very recently started playing a little bit with the SyncML API, and since it's not very difficult to get something basic working I might implement some support for this sooner or later too. Yes, this would be amazingly stellar for mobile apps. It appears that messaging is a big missing piece right now, so tinymail with some extensions would be an amazing opportunity in the messaging arena. What is the current extensibility of tinymail? How could we go about adding SMS support to tinymail to treat it like a first class piece of mail? Jon ps. I will be at FOSDEM so if you see me, feel free to ask me any question about tinymail. -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: my 2 cents about Idea: ring tones and other non-software assets can be developed as CC content
On Wed, 2007-01-31 at 21:45 +0300, Marc SERT wrote: It's very pleasant to see this fireworks of ideas. can i add my feeling about usability of this device : think about impaired people like blind people: it will be very nice to help them to discover the virtual keyboard by for example a continuous bass sound modulated by proximity of touch. and please : each numeric key a fixed sound, why not the standard tone (or pulse?) remember the first modem you use ATDT ATDP :-)? and an other big opportunity : in the way of a special big Grand'Ma icon to launch call to police station or an other number with a prerecorded sentence . I am Mrs GrandMa and i need urgently your assistance . please help me at the following place... and the gps coordinate with the microphone open so the evalutaion of situation is very fast. This grandma icon would be great for kids too...rather than some disabled device, this one could be for all ages :) Isnt it great? Yes, accessibility should be thought about in this type of competition for ringtones and other content. You can save a lot of lifes. The next personal Argos system.. Sorry for my english i read better than i write Better than my french :) If you need a french translator Marc This is great! Please add to the wiki: http://www.linuxtogo.org/gowiki/OpenMoko/Content I made that page licensed under CC BY (so we can move it easier to the real wiki soon)... Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: http://en.wikipedia.org/wiki/Wiktionary Re: Translators needed?
Op 31-01-07 15:22, Robert Michel schreef: Salve Engin! On Wed, 31 Jan 2007, Engin Erenturk wrote: In my opinion the translations must be done professionally for such a product like this. Instead of volunteers who are not professionals, volunteers who are professionals and volunteer who can provide a professional translation must localize this product. I localized RSSOwl into Turkish, and I gathered 3 of my friends and discussed every one of the phrases translated. But in the end it is not like a professional translation. It's very important to give the same meaning of the sentence in the localized language instead of pure translation. Sometimes it is very hard to do such a thing. The best example is the Microsoft products, even I don't support or like them, they did great job in localization... They got a big book of meanings of words/phrases which are used in Microsoft products, books etc. If someone wants to do a translation for the books etc. they gave this didctionary to them to use it as reference dictionary... As I said if there are volunteers who are professionsals and who can localize it with professionals must be found... I'll try to get in touch with a professional translator who is experienced in technical translations if there is a need for Turkish localization. I would like to disagre. Open translation has the big advantage that people could give feedback about the translations - many opensource projects include the wikipedia are working without the support of professional translators. Getting in touch with professional translators would help in some rar cases of doubts/dispute. IMHO more important is that the people who translate does know what the software device do at that moment. Hi Rob, First, as Engin already wrote in another response I think, open and professional are not opposites. His suggestion is, if I understood him correctly, to find volunteers who are already software translators professionally. Also, yes you are correct that many opensource projects [...] are working without the support of professional translators. And it shows. I absolutely do not intend any disrespect with that-- I'm really very grateful to the people (volunteers mostly) who make OpenOffice, GNOME, Evolution, Thunderbird, Firefox, etc. etc. available in Dutch on my home Linux box, so that also my wife can use the system comfortably. However, there definitely are many problems: inconsistencies between applications, inconsistencies with Microsoft software (yes, unfortunately this is important), different views of translators (most keep the English website, some translate it to the horrendous neologism webplek), missing translations because the translation could not keep up with new releases of the application, etc. Such problems are minor, in the sense that they usually do not block understanding of what is going on, what should I do next, etc. But they make the experience less polished and more botched. And for a device that we want in lots of non-developer hands, we need polish. Translation is a thing that Microsoft does really well, as far as I've seen. In my opinion, the officially-blessed-by-OpenMoko software feed also should aim for a high level of translation quality, consistency, and completeness. So again, professional volunteers are welcome :-) Groetjes, Marnix ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
