Re[2]: Video of production device?
-Original Message- From: Vinc Duran [EMAIL PROTECTED] To: List for Openmoko community discussion community@lists.openmoko.org Date: Fri, 23 May 2008 18:51:00 -0600 Subject: Re: Video of production device? Is there video of the production FreeRunner in use? I found http://illume.projects.openmoko.org/illume-vv-01.avi posted by Kevin Dean on May 19th. Is that video of shipping software or just a concept video? If someone cares I dislike such UI.Even on video playback it can be seen that sometimes some sliding effects are somewhat slow.And, what is slightly worse, UI has too few items per screen and over-uses this nasty sliding.So on this video I can see just a permanent nasty scrolling and sliding.IMHO such UI is neither well optimized for stilus- or finger-driven UI nor comfortable in sense that there should be as few levels of nested menus as possible.From video it looks like dealing with such menu system is a real PITA.Sliding is great effect and looks great and I like it.If it's not overused as here in this example. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia Vs. GTK or both?
-Original Message- From: rakshat hooja [EMAIL PROTECTED] To: community@lists.openmoko.org Date: Sat, 24 May 2008 18:17:03 +0530 Subject: Qtopia Vs. GTK or both? I am not to sure how many people have seen the Neo software stack diagram on the wiki but after looking at it there really should not be a GTK Vs Qtopia argument any more. But I do wonder how Android fits in? As for me, I'm preferring to have both GTK and QT based apps on board.Both suites have cool apps.So, on desktop system I use best apps from both suites.Dunno see strong reasons why this can't happen on mobile devices.Furthermore, Nokia goes this way with their n8x0 tablets and as a device owner I like this step. P.S. as far as I understand, Android just a java-based crap which ONLY uses Linux as low-level engine, without any native apps or UI frameworks like QT or GTK.Hence it is pretty useless that it runs Linux and I see no real reasons why Android will be better than dumb dialers running proprietary OS + J2ME on top.Linux has quite little use if there will be no real fully-featured apps to use it's power and Dalvik VM is actually, proprietary.From another side, being able to run Android\J2ME apps in addition to lightweight, fast and featured native apps is a benefit which can turn device into a powerful competitor on smart phones market. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re[2]: Video Playback virtually impossible on Neo Freerunner? (Re:Video of Qt 4.4 on Neo1973: brings iPhone like graphics)
Mikko Rauhala [EMAIL PROTECTED] wrote: On ma, 2008-04-28 at 09:26 -0500, Tim Shannon wrote: But isn't it still limited by the bandwidth available from the micro SD card? Maybe I misunderstood that. Yes it is. It's just that sending mpeg4 packets to the glamo takes just a _tiny_ bit less bandwidth than sending entire uncompressed frames. (Also the CPU will have more time to spend for doing the I/O.) But anyway I have to admit that n800 which has comparable resources (400MHz ARM11, quite big 800x480 screen with quite data slow output, SD\MMC cards which causes a decent load on CPU on heavy I\O, etc) is able to play videos with Mplayer pretty nice.Virtually any MP4 of internet quality plays well.And even lots of CD-sized DIVX movies (someone calls this DVD rip) are OK without recoding, though they're wasting lots of space on card and you may want to re-rip DVDs with more optimal parameters set or recode (the only hardware cheat is hardware picture resizing which takes no CPU cycles).Actually, video looks quite good and I'm pretty sure that such things as Neo *can* play videos.At least some of them.As for hardware decoders I have to mention that they tend to be picky in what they're willing to decode and what thy're refuse to decode.Actually, n800's DSP MP3 decoder for example refuses to decode certain MP3 streams.True hardware decoders are often even more picky and people usually hate that.Software decoders are less picky and willing to play much more formats and even semi-bugged or semi-damaged data (and once there is waste numbers of codecs on planet, you'll encounter such crap sooner or later). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SIM Card Copy
I just had an idea that I got from a couple of devices, how about a virtual SIM card? Is it possible to make an ISO of a SIM card and store it in the Neo to be, for lack of a better word, booted from? In general, no. SIM card is a bit more than just a dumb file system.It does has own CPU, file system, etc - all in one IC. When network requests subscriber authentication, request (with random number) is in fact passed to SIM card. Then SIM does computes proper response itself and returns these data to the phone. You can not compute response yourself without having proper card's internal key, known as Ki and once request is a random number, you have no way to craft proper reply without having correct Ki key. This Ki key is being written to the card at manufacturing time.Then, ETSI specs require Ki file to be invalidated.I.e. this file becomes available only to card itself and it's built-in software only.But it should be never sent by the card to outside world.So, card can compute auth.Nobody else can.Except operator's hardware where another Ki copy resides so this hardware can repeat same computations and check if our reply to request is correct. Well, in real world all things are not as ideal as it was intended to be.At least some SIM cards still can be cloned.Initially, algo had cryptographic flaws allowing to recover Ki key if enough responses collected.So there was softwares which issued lots of requests to card and then recomputed Ki key using obtained responses.This requires some noticeable time and physical access to SIM card.However even this does not makes operators too happy.So today most cards are either limited in a number of requests they're willing to serve during their life and dying when this number is exhausted (this causes card to die somewhere in the middle of Ki recovery attempt) or networks are updated to use newer auth algos without such flaws.Cards which are using newer algos can not be cloned since you can't recompute Ki even if you have lots of responses collected.So, in modern world lots of cards can't be copied.You can backup some stuff like SMSes or phonebook or other crap.But you still can't pass authentication without having a real SIM card. Theoretically, phone can compute authentication data on it's own, making virtual SIMs possible (and at least Siemens Mobile did implemented virtual SIM stuff in their phone firmwares for testing and debugging).On a practice however things are limited by your ability to get proper Ki and only if standard auth algo used by the network.In general, you can't expect this to work.Also in OpenMoko hardware design it is probably Calypso GSM modem IC who handles all this low-level GSM network crap on it's own.Inside it's own closed proprietary firmware, making things even harder to implement.I suspect that proprietary firmware is also heavily protected against any unauthorized modifications (Ti is known to be quite paranoid on security stuff).So, this is both hard to implement and OpenMoko isn't a best choice here as well. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /. : Feds Have Access To Cellphone Tracking On Request
i wholeheartedly support this open platform that gives its users the control to turn -any- of its radios on or off at will (of the operator...). This will not help too much.Either you're not in the network or network should be aware about your location.When someone calls you, network have to select a proper Base Station to enroute call to your mobile, don't you think so?If network has no idea where you are, there is no place to route call.Call fails with subscriber is not available, blah-blah-blah message.Simple?;).Surely all this can be (ab)used.But I see no any realistic way how to avoid this completely.At very most, it is possible to relax things a bit but you can't avoid tracking completely because this means network is unable to route incoming calls to your phone. So... - If you're just an average Joe, relax and enjoy by your 'democracy'.Total control.Sounds so democratic, isn't it?That's how democracy works, after all :P - If you're an IT pro and really willing to do something unfair, you're probably know how to avoid this dumb issue anyway ;) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Login Manager
Jeff Andros wrote: simple... display contact info(email, friend's phone number, etc) to return the phone at the login screen... This will be a pretty good reason even for quite dumb evildoers (who is not willing to return device to you on their own) to reflash device with default\empty image to get rid of this info to make device looking like their own.And location tracking will stopped by reflashing as well.The only way to avoid this scenario is to make such people to believe that device is in almost its default state without any restrictions set and is not going to act against them so they will leave current firmware as is and it can still silently track phone's coordinates and report them to a real owner, giving a good chances to get your device back even if those who uses your device did not planned to return it to you. I think my old(~2000 ish) WM PDA had an option to do that... people can't get into the phone itself, but they can figure out how to get ahold of you Yep, in IDEAL world filled with only good people it can work.But in REAL world lots of people will prefer not to return device to you but rather to remove stupid lock and use device on their own or sell it to someone.It is not too hard to remove lock and hence chances to get your device back are not very high and depend too much on who is a new device owner.If this is good person with fair intentions who is willing to return device, this will help.But if for example some a$$hole has just stolen your device, do you really expect (s)he will return device to you?Unlikely I guess ;).However, if phone (silently!) reports too you locations where a$$hole can be found, it is quite trivial to get your device back.However this tactic requires that new owner to believe that device does not restricts it's usage in any way, etc.Adding info about owner slightly increases chances that device will be reflashed to reset this info, etc.Setting a hard lock will cause quite high probability that device will be reflashed\unlocked to get rid of lock. -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
hank williams wrote: I think that this is not useful at all. Actually it would be quite useful. I'm do not thinking so.It will waste valuable space in Subject column of message list with STUPID and REDUNDANT tags which carry no useful info at all and just wasting space in Subject column of messages list, leaving less space for really useful subject lines.This will not make things better I guess. Without such a header I am unable to *visually* distinguish between this Why do you need to do this, at all? You can just set up rules to move messages on arrival into separate folders (based on Sender field content for example).Quite easy rules and this works perfectly.So I'm for example have this mailing list in one separate folder.And another lists in another folders.Simple and works, offloading my brain to more interesting tasks than visual distinguishing of mail messages from mailing lists.I'm using Thunderbird but I guess almost any full-featured e-mail program can do this for you, freeing your brain for more interesting things than sorting e-mail by your own eyes.Crafting such simple rules takes some 5 minutes and then reduces load on brain greatly so you do not need to spend yor time on visual distinguishing at all.Let's machine to work and humans to think.It is a bad idea to execute machine work (like sorting dozens of messages by criteria) if you're human. and other mailing lists or mail. Filters are useful for organizing, but I personally prefer to see my whole inbox and to view and scan all inbound content. Imho mail list is rather resembles newsgroups than e-mail so it is strange to have all things in common place - this will render your inbox into huge Junk e-mail folder :).Of course nobody can forbid you to do machine work like sorting mail by criteria on your own but I guess there is lots of more interesting things to do :).And well, yes, I did located all mail lists related folders as subfolders of Inbox folder.So, I can still scan through all incoming mail if I really need this.Let's admit that automatic move of mail lists to other folders makes a lots easier to find and handle usual (user-to-user) messages.Otherwise it rather looks like dealing with huge Junk email folder :D Of course the other thing I always complain about is that this is the only mailing list I am on (out of 10) for which (at least in gmail) replies to a thread go to the individual and not the list unless I say reply to all Let's agree here, this is a bit annoying thing.I did not seen other lists with such strange behavior.Imho if I'm clicking Reply, default action should be reply to list and not to a specific user.And even if you'll Reply to all this causes To to contain author of message and CC to contain list.What is the clue to bother author with personal (user-to-user) message?If author needs reply, (s)he is reading mailing list as well, isn't it? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Login Manager
Shakthi Kannan wrote: Hi, This is w.r.t. having a login manager for OpenMoko. I am not sure how other PDA phones implement login access, but, in the Nokia 6210 classic, even without the SIM card, it simply allows access to the phone, organizer applications, and data. So, if the phone is lost, valuable information will be stolen, which is something end-users don't like. So far, virtually no phones protect USER data well enough.Actually, proprietary phones are doing some job at protecting their firmwares from hacking and pretty powerful protection in operator locking part, etc.And er, virtually no protection of user data.While locks, etc are encrypted and heavily checksummed\signed, user's data are stored as is.So anyone with physical access to phone can quite easily dump your private data if they' really want to.Basically this can be done by just over wires.At very most (uncooperative boot loader, etc), they have to use JTAG or desolder flash IC.Not a great deal for pros.So, once you lost the phone you have no reasons to feel your data too secure.They are not secure. And user's phone code often implemented in very lame manner - usually it is trivial to remove it or dump it's value.So, no, if you your lost phone, phonecode will rather cause it to be removed and phone never returned to you.While fair people will be effectively prevented from contacting you.So this can even work against phone owner. I can see two different approaches here. 1) You care about your data and do not care too much about phone is returned to you. The real way to protect all user data from unauthorized use in quite powerful manner is to use file system encryption.This will make all things protected.Phone book, calendar, notes and all your files.This costs though. Filesystem will be slower and due to heavy CPU use battery will exhaust faster. Everything has it's price, privacy too. If someone is willing to implement this ever, there is funny hint, just invented by me: long password is pain in the ass to type at boot time.And short password is easy to bruteforce. So, you can store long encryption key in SIM as phone number and name in SIM address book.Access to SIM is protected by short PIN which is hard to brute since you only have 3 attempts to go and SIM is pretty secure thing :).So user have to enter just short PIN but this will cause powerful encryption key to become accessible from SIM's address book.And those who do not know pin will not have access to this key since SIM cards are refusing address book access without entering proper PIN code IIRC. This can make data pretty secure.But... evil persons will just erase all this and reload factory flash image so they can use the phone.Good persons will be prevented from contacting you up to some degree since phone gives no access to address book.Idea with displaying your contact info on boot splash\password request screen can help though. 2) You do care about phone return and do not care too much about unauthorised data access. Then another approach can be good: phone should allow all access to all data as usually, any SIM should be OK, etc.Recommended setting is no PIN and no phonecode.But it should silently send it's coordinates to let's say, e-mail to your mailbox or SMSes to a friendly number(your second phone number or friend, etc).SMSes will also expose bad guy's phone number to you (your friend, etc).So, bad guys can use phone and access all your data.But it will silently track them a bit so you can return your phone easily.Actually there should be no restrictions in data access or features.Otherwise phone will be reflashed by evil people and tracking will be stopped so your chances to find your phone will become pretty low (IMEI tracking is proven to be quite ineffective since not each and every operator on the planet does this and they're cooperate poorly enough). Well this will leave all or some data accessible to bad guys.Tracking their location and new SIM's phone number in exchange. I see no effective way to combine these 2 different goals.One is prevents access to data but this will enforce bad guys to do full reflashing.Killing your (unusable) data but getting working (usable) phone.Another approach makes guys to believe phone is not defends itself and not secured.While it really silently tracks evildoers. I read this page: http://wiki.openmoko.org/wiki/My_Account I put together few points on the login manager: http://shakthimaan.com/downloads/openmoko/docs/login-manager.pdf I am not sure if I have missed any user scenarios. Thoughts/suggestions/feedback appreciated. Just replace .pdf to .odt in the above to get the OpenOffice document. If login access has already been addressed in OpenMoko, please let me know. I hope this is clarified before mass market. Thanks, Shakthi ___ OpenMoko community mailing list community@lists.openmoko.org
Re: Audio Jack 2.5 mm
Vladimi'r Lapa'c(ek wrote: Interesting thing to consider is how many people would like to use the headset and how many would it use for playing music. Wired connection usually preferred by those who listens to music.Others are often using bluetooth since it is more convenient (no wires).Usually I can see people with wired headsets only if 1)Wired headset was supplied with device by vendor and owner is too lazy to buy something else. 2)or owner likes music, bluetooth is not an option here due to lack of a2dp support by devices and quite low quality of headsets. As for me, I will prefer to listen to music on my phone (I'm already do and will do in future, that's just convenient).And yes, I will have headache with buying 2.5 to 3.5 mm jack converter since handsets with 2.5 mm jack are pretty low-quality and only suitable for calls (and for just calls, bluetooth is more convenient option). My estimate is much bigger for the second, but it may be pretty much skewed. Using an adapter might be an option but not for mainstream (I know, the phone is not mainstream). These adapters are popular up to some degree due to some portable devices using 2.5 mm jacks, but still this adds some headache with finding such adapter.That's not fair, at least for me. P.S. but 3.5 mm sockets are bigger than 2.5 mm ones - this may be an issue for small portable devices. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Richard Stallmans standpoint about openmoko
Simon Norberg wrote: Hello, I mailed Richard Stallman a while ago regarding a few things including what he thought about openmoko and his answer was: I could endorse it if they get rid of the plan to use non-free software for the GPS. I don't think the answer surprise anyone, but atleast we know for sure now. And i really hope we can replace the non-free GPS software as soon as possible or atleast before the public release. Regards Simon Norberg As for me, I'm have to ask few unfair questions. 1) Why there should be some closed-source daemon which does some unknown things?And why should I trust it, if I have no idea what it does? 2) As I understand, to fully use features of AGPS I should send some data to some server over network, without really having any idea what they will do with these data, if they will collect them for later use and if my privacy protected here or not.As far as I can understand I can't set up my own server to connect it via secure channel and hence to ensure that privacy level and data handling policy is acceptable for me.Right? Of course it is possible to do some sort of tracking with GSM and there is nothing you can do about it (you have to announce network about your presence to be able to receive calls, if network has no idea where you are, incoming call will fail with the subscriber is not available at this moment...).But GSM-based tracking is low-precision (something like 500meters wide ring around serving cell or in worst case, cross of 500-meter wide rings if more than 1 serving cell were used) and only possible when phone calls, transfers data, etc.GPS allows to do much more high-precision tracking and this seems to be somewhat unfair idea to send gps data to some server without really having idea what they will do with these data and which data collection policy is really in effect. Sorry for being paranoid a bit. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Widgets: Openmoko/Chumby transproject?
Florent THIERY wrote: Disclaimer: in no way I'm any official or whatever - I'm just a subscriber of this list like you.All following thing is just a my own private opinition.Other recipients or officials may feel this in slightly another way. As we can see, the neo and the chumby have a lot in common, be it ideas, hardware specs or even leaders ;) Yes, it uses flash7 for widgets. Which has'nt even been considered in the openmoko case... But what if the two projects shared the widget aspect? If you're about Macromedia Flash (er, now Adobe), isn't it closed source?There is already some Linux phones where only kernel and a very small amount of user-space things are open and remaining components are proprietary.Then, why there is need to have one more phone where only kernel is open and everything else is closed-source?Also while flash player is proprietary, I also see no any good opensource tools to create flash animations as well.And well, flash is never fast - due to it's nature it is very CPU-intensive.I'm already had fun with Siemens mobile phone with awfully slow Java-based menu.It was so slow and sluggish that users are now hacking this proprietary device to allow developer mode and use native-code menu which is much faster.It is real pain in the ass to use such devices and wait for device's reaction after each action.IMHO UI (or should I better say, MMI?) is good when machine waits for human actions.Not when human waits for machine's action to complete after each click. http://www.chumby.com/widgets/channels This link unfortunately requires me to login to get it working. I hope this is not a site advertising? The two products could share: * embedded experience * the content ecosystem * the display platform (flash) and tools I'm not saying i want this. But: why not? I'm stated my point of view.Personally, I will never buy open phone where UI toolkit is heavily based on closed source thing and requiring me to buy proprietary Adobe app to create\change UI parts.That's hardly in open source spirit.Also, flash based UIs I seen while looking good are quite slow and jerky even on powerful (and power consuming) desktop machines so they're hardly usable.Of course this is my own private opinition and it is safe to ignore it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Itch3: Anti-lost/theft protection
Marcel de Jong wrote: On 3/4/07, t3st3r [EMAIL PROTECTED] wrote: snip FYI: just to let you know, an anti-thief\anti-lost system for phones already exists.Here is the story.Maybe someone already heard that proprietary Siemens mobile phones (x55 series based on 80C166 CPU and x65 and x75 series based on ARM9) were reverse-engineered deeply and people has bypassed boot loader protection (preventing user's code from being uploaded) so everyone can run it's own code on phone's CPU.Also I heard some other vendors were hacked successfully as well.Some SonyEricsson for example. One of the first firmware patches has been the anti-thief subsystem.How does it works?It does detects SIM card change (by IMSI checking IIRC) and then SMSes to predefined number(s) (should be someone of your family or friends of course).This reveals new phone number (allowing to take a legal actions) and can allow owner to regain remote control, get coordinates (actually, on Siemens phones you can get Cell ID at very most, funny enough anyway). But how does this affect resale of the device? Because then the new owner inserts a new SIMcard, and then this mechanism would go active, wouldn't it? This subsystem was invented by geeks and intended for smart users only - you have to apply binary patch to firmware to use this. Of course you have to shut this subsystem down before selling phone. Or tell new owner how to deal with it if he\she is smart enough.But actually I have to admit that before selling phone it is a good idea to 1) revert all patches, if any (upload factory firmware) 2) reset all phone settings to factory defaults (and address books\SMSes as well) 3) revert filesystem to factory state. At this point at least you're free from being bothered by new owner with any sort of firmware\settings problems and do not leak your private data.Ideal solution is to make FULL firmware backup of new phone (whole flash IC dumped) and when you're about to sell phone, just upload this backup before you're selling it (therefore returning device to backed up state, completely trashing private data and all things you messed up).Unfortunately, at home this is possible for some phones only (yep, Siemens phones for example) and this may require unreasonable efforts for some others. I'm just curious, it sounds like an interesting idea. Btw there is some problem.If this solution is default and popular, thieves and lucky people may become aware of it and may do something against this.So in general this will work only while solution is not very popular\custom\invisible. snip --- Marcel de Jong ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Itch3: Anti-lost/theft protection
Paul Wouters wrote: On Wed, 28 Feb 2007, Wolfgang S. Rupprecht wrote: Personally I like the idea of periodic SMS messages with the lat/lon/altitude. When in stolen mode, having the phone receive SMS msgs containing commands for the phone would seem to be very useful. The first thing that happens to a stolen phone is that the SIM is chucked. You won't be able to *send* SMS messages, since you will not know the phone number. Unless you make sure it SENDS you its new phone number as well. FYI: just to let you know, an anti-thief\anti-lost system for phones already exists.Here is the story.Maybe someone already heard that proprietary Siemens mobile phones (x55 series based on 80C166 CPU and x65 and x75 series based on ARM9) were reverse-engineered deeply and people has bypassed boot loader protection (preventing user's code from being uploaded) so everyone can run it's own code on phone's CPU.Also I heard some other vendors were hacked successfully as well.Some SonyEricsson for example. One of the first firmware patches has been the anti-thief subsystem.How does it works?It does detects SIM card change (by IMSI checking IIRC) and then SMSes to predefined number(s) (should be someone of your family or friends of course).This reveals new phone number (allowing to take a legal actions) and can allow owner to regain remote control, get coordinates (actually, on Siemens phones you can get Cell ID at very most, funny enough anyway). Btw, few interesting things to mention... - People did implemented own run-time and executable files loader.It loads ARM .ELF files (lots of arm compilers can produce these files).Amazing hack.It allows direct code execution by user on main phone's CPU easily (almost as easy as launching Java apps). - Trojans do you say?Well... you should be a real idiot to download real executable code from untrusted place.Anyway, I _never_ heard about ELF trojans and even Window$ Mobile allows to run unsigned code but it still lacks trojans hell as well.But there is already JAVA trojans targeted for USUAL restricted phones.Virtualization does not helps.Users are often stupid enough to confirm Java SMS send few times before they recognize it costs them few US $ per sms.The ONLY way to prevent abuse is to make users smarter. Otherwise no matter what is protection, it will fail due to user stupidity.The only perfect solution is either to disable to execute anything (even Java!) and have dumb dialer instead of smart phone or to educate users a bit so they're aware of potential issues. Also I guess that there is very few native code trojans just because stupid users are usually using stupid phones (which are able to dial and send smses and able just to run Java at very most) since they're cheaper.Smart phones users are usually smarter itself (they have to know why they're paying for more expensive device, right?) and hence they're less vulnerable to trojans. - Also I have to admit funny thing.Those cell operators who afraid of network hacking and disable to run native code on the phones because of this are a *real morons*.There is already a dozens of hacked phones where user's code runs on main phone's CPU and while this is 1-chip solution, this code has COMPLETE access to cell networks, their internals and can craft absolutely any data to network.However I never heard about cell operator network hacked.But if someone will decide to hack network, he has just to use own hacked phone, replace SIM to target operator's one and (possibly) craft IMEI allowed to log in to network (perfectly possible of course once your code has full control on the whole phone, this can be illegal in some countries but hacking networks is illegal as well so who cares?).So, operators are better to secure their networks.Disabling to run native code just will cause users unhappy but it will actually never stop persons with evil intentions from doing something wrong with network.Actually looks like an ostrich :).Hiding just an head will not save their ass, even if they can no longer see danger when head is hidden. Something as simple as having a way of remotely submitting a short shell script would do the trick. Stuffing something useful in 160 chars is hard. It's better to design things beforehand, so you can just send simple commands with arguments. I wonder if you can send SMSes on the Neo without the user noticing anything, or wether things like the backlight will be turned on (by the closed off chip hardware). Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wifi again
David Schlesinger wrote: This is a BIG hardware design mistake IMHO. I think you should go right out and build your _own_ phone. Tell us all about it when you get done. Kinda strange reply. I have to admit your reply is completely useless and even looks like an insult. Next time please keep such phrases to yourself, your family, dog or even /dev/null unless you're openmoko official (and if you are, it is ok to unsubscribe me then, since I'm do not like idea to spend my time on peoples who posts useless insults as reply). As for me, I'm want to see openmoko success. I did pointed that lots of people are unhappy that there is no wi-fi (just seen reaction on few linux fan sites). What's wrong? It is forbidden to report weak places which are able to affect project's success? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wifi again
Joe Pfeiffer wrote: Another, probably better, option is a bluetooth access point. Yes but it will have insignificant coverage. So it will be hardly limited to my home. Still something and better than nothing. P.S. As for me, I'm still do not understand, why there is no WI-FI built in. This is a BIG hardware design mistake IMHO. Linux without network is something like North Pole without snow. And the only somehow popular networking in public places is WI-FI. This has been discussed many, many times in the last month. According to Sean, no wifi chips that both are low-power and have open specs. Hmm. Sorry for bothering once more then. Much more helpful reply compared to spam from David Schlesinger, thanks :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wifi again
Oleg Gusev wrote: Am Samstag, 17. Februar 2007 12:24 schrieb t3st3r: P.S. As for me, I'm still do not understand, why there is no WI-FI built in. This is a BIG hardware design mistake IMHO. It does not make sense to complain here about the (missing) hardware features. Okay, stopping it. If you urgently need wifi in a phone take a HTC model where the ACX100 chipset has Linux support (Universal). Will consider buying it only if they'll use linux by default and if it will not be crippled in bastardized manner. Bastardized means for example, when some assholes we do know better than you what you need can have hardware or proprietary crapware implementations which are prohibiting kernel modifications or software installations - this interferes with GPL spirit even if formally can be ok. And there should be vendor support and reasonable community around so there is dozen of programs ported, etc. Otherwise they're better go to the hell. IIRC, HTC does runs Windows mobile by default and it is too optimistic to assume one people can hack Linux in and then port significant amount of programs in just one face. Maybe it is possible to have some community around it (I heard someone already porting or ported linux to HTC) but I guess projects where Linux is a default OS have much more chances to gain such community, so thing can become somehow popular and succesful. Just compare Nokia 770 vs pocket PC devices hacked to run Linux.What is more popular? Where lots of software and big and helpful community? I guess same case here. I.e. hacking linux to HTC and getting wi-fi to work is not impossible ... but is it really worth of [my] efforts? I guess answer is probably NO. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: R: Camera and MMS
Andreas Kaeser wrote: Michele Manzato wrote: Voting for integrated Camera as well ... Well, as much as I would like a camera in my all-in-one gadget, it would be prohibitive for my every day use: in my working environment anything capable of picture recording is strictly disallowed. So I wouldn't be able to use Neo1973 :-( So what? Jailed people are often disallowed to use mobile phones at all. Should mobile phones manufacturers to give up and stop producing mobile phones at all then? [off] I'm amazed how easily people are giving up their legal rights in favor of semi-illegal corporate policies (or similar stuff) which are trashing human rights to the hell. As for me, I'll never work in such jail-like environment. Do you want to have open and free gadget ... but still have jail-like job?Amazing!Freedom is not just a word - it's way of life. Think about it. Twice. [/off] I guess people working under such conditions are less than 10% of total population, so maybe we won't be considered too much. A pluggable camera would definitely help! As for me, I will never use pluggable camera.Its a separate thing which can be lost, forgotten and broken easily (the plug itself is a weak place).And it reduces device usability to the hell.Early mobiles attempted to use pluggable cameras but it looks like this attempt has miserably failed.It has been incredible unpopular idea and died without success.However I have nothing against the following: two models, one with camera and one without it. However I have no idea how hard and costly this to implement (usually, developing 2 devices costs more but probably dropping features is relatively easy - just do not solder some parts on same PCB and use a bit altered case). P.S. Of course you can safely ignore my dumb mumblings but before doing so, consider that I closely dealt with mobile phones internals since 2000 and usability is my primary job. 2ALL: sorry for semi-flaming message. Andreas ___ 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: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
[EMAIL PROTECTED] wrote: For instance: Proposed wiki page: How to respond to list email: 1. Never remove any re: in the message subject. Some (not all) email clients use this to identify the thread. 2. If your email client adds the original poster and other addressees to the Cc: field, remove them. You should always respond only to the list. This will not work. Defaults will prevail. Everyone will do at least few replies with these ugly CCs before (s)he will get idea that something is wrong.Already tested on my own ass - got some of these double-messages just now. Real fix: set up mailing list to put its own address (community@lists.openmoko.org) into into Reply-to: header and instruct people to hit Reply (not Reply all).I hope google cares about this header as well? These CCs are possible even with regular mail client, too. With default state of things I have to remove original sender manually and insert mailing list into To: field instead. In no way I want to mail to original sender directly when using mailing list. P.S. I'm stopping replying to this google story thread. It isn't interesting - flame mode off. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
