Re: Root password and ssh?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd have to ask why your music files and images are owned and readable only by root. Doesn't make much sense. You don't run your media player as root, do you? Config files should be chmod 640 to root, and certain executables as well, but content and such should be in the arena of normal users. And you WANT to inconvenience your users if they are trying to do something as insecure as logging in over ssh as root. I do hope that OM isn't set up to run everything as root by default... Mo Abrahams wrote: | Except for if music files, images etc. on the phone are owned by root, | in which case we wouldn't be able to access them via ssh. | | On Wed, 2008-05-14 at 09:54 -0500, Stephen Shelton wrote: | Why not disable login as root? Seems pretty simple, and IMO a good practice in | general. I assume logging in as foo user works as normal...? | | | | ___ | Openmoko community mailing list | community@lists.openmoko.org | http://lists.openmoko.org/mailman/listinfo/community | | - -- ~Bradley Hook Education Systems Administrator Kansas State School for the Blind 1100 State Avenue Kansas City, KS 66102 Voice: (913) 281-3308 ext. 363 Mobile: (913) 645-9958 Facsimile: (913) 281-3104 http://www.kssb.net ** Confidentiality Statement: This message and accompanying documents are covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, and contain information intended for the specified individual(s) only. This information is confidential unless explicitly indicated otherwise. If you are not the intended recipient or an authorized agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, copying, or the taking of any action based on the contents of this information is strictly prohibited. If you have received this communication in error, please notify the sender immediately by E-mail, and delete the original message. ** -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKzNsdLuK9oP1lmYRAhJ5AKClESkNOFWFHFLAg0FP7hmY8vi7hgCffCOf j1eNnA6B51s0IBKejYaRcFA= =uHph -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: PS3 Logitech Wireless Keyboard and Moko
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have the same keyboard, and the timeout disconnect was due to a configuration issue in the BlueZ stack in general (I don't have a Neo yet, this is with a regular Linux desktop). I updated the configuration file (can't remember exactly what I changed), and now it works just fine. ~Bradley Christopher Earl wrote: | I bought a PS3 wireless keyboard, this BTKB has a mouse pad and buttons, its a full qwerty keyboard. This Works Great with the GTA01, the mouse pad even works, only issue is that it has a timeout that causes moko to disconnect , which i will fix with a script. just thought I would let everyone know | |--KrisAbsinthe on irc | | ___ | OpenMoko community mailing list | community@lists.openmoko.org | http://lists.openmoko.org/mailman/listinfo/community | | - -- ~Bradley Hook Education Systems Administrator Kansas State School for the Blind 1100 State Avenue Kansas City, KS 66102 Voice: (913) 281-3308 ext. 363 Mobile: (913) 645-9958 Facsimile: (913) 281-3104 http://www.kssb.net ** Confidentiality Statement: This message and accompanying documents are covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, and contain information intended for the specified individual(s) only. This information is confidential unless explicitly indicated otherwise. If you are not the intended recipient or an authorized agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, copying, or the taking of any action based on the contents of this information is strictly prohibited. If you have received this communication in error, please notify the sender immediately by E-mail, and delete the original message. ** -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHucv0dLuK9oP1lmYRAuCBAJ0SIUZKFx2ECmMdufvs7NTqCCQ85ACdFKJw 3MhZg21Rj0RqrhJp9KgUdPk= =OxP4 -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
How much juice does the display eat up when it's active? I assume it's a considerable amount. Could we have the ability to drop the phone into a minimalist mode, where all the fluff is disabled but bare-basic features continue to work? For example, kill the wifi, GPS, bluetooth, and even the display. If you are in a crunch and want to extend your phone's call-time capacity, you could probably deal with approximating a 3 col, 5 row standard phone keypad on the touch-screen WITHOUT the screen displaying anything. Maybe it's a silly idea, but I know I find myself stuck all the time in a situation where I wont be able to get my phone back on a charger like I had planned to. When it comes down to it, the Neo is a phone first, and I'd rather have it act as such when I'm in a bind. ~Bradley Michael Shiloh wrote: Nick Guenther wrote: On Feb 8, 2008 4:04 AM, Michael Shiloh [EMAIL PROTECTED] wrote: Hello, I've researched this a little, and this is what I've learned: 1. We are still looking at a number of different batteries, so there is no final capacity or feature set determined yet. 2. The capacity will most likely be around 1200mA. If you find any place on the wiki that says something other than 1200mA, can you please make the correction? You may reference this email. Oh. That's... really disappointing. The battery life is already unusable, and the faster processor and wifi will just make this even worse. We are well aware of software changes we need to make in order to improve battery and have simply not had the time to do this. You can expect much better battery life when we implement these changes. In fact if you look in the archives of the kernel mailing list you will see that a tremendous amount of progress has happened over the past few days. I think the current SVN code supports a much improved suspend mode that my very simple testing suggests should last for well over 12 hours. And work continues. Michael ___ 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: USB host
** * Moko * ** | - USB Mini Jack | |\ - Splice the Power from the hub to feed Neo | \ | \ | - USB-B Jack \ **| * Hub *| **| | | - USB-A (Power from hub)| | \_/ | | - USB-A Line to standard USB device I would think this would work to charge the Neo while in host mode. If the hub doesn't support a non-powered host, you could always use yet another port on the hub to power that connection (creating another loop). It would eat up 2 ports on your hub to do this, but I would think rigging custom cables is a bit easier than rigging custom hubs. Just my thoughts. ~Bradley Giles Jones wrote: Lars Hallberg [EMAIL PROTECTED] wrote : I'm still not clear over this... 1) Will it be possible to charge the neo over the usb connection while the neo is in host mode. Will that raise special demand on the hub? It will be if you use a special cable which allows power into the Neo but not out of it. 2) With 4 AAA batteries in the hub You don't want to charge the neo at all. If you have wall power You want to fast charge... Can that be controlled from the neo, raise any extra demand on the hub? You would only connect the data lines from the Phone to the hub. You need a cable which allows power into the phone from a PSU, then supplies a hub with the USB data lines. --- G O Jones ___ 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: virtualization of OpenMoko...
From the Wiki: Win32 binaries shipped with firmware can be downloaded from openmoko-emulator-win32-bin-20070514.zip. Tested on MS Windows XP. The link points here: http://mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070514.zip ~Bradley [EMAIL PROTECTED] wrote: I haven't tried it yet, but I presume that it should just work*. 1. Install VMware for Windows on your computer 2. Install Linux as the guest operating system. There used to be an Ubuntu image ready to go on the VMWare website. 3. Following the instructions on the OpenMoko wiki, install mokomakefile and and QEMU I don't have a Windows computer, or else I'd try this. I just noticed that you are local. If all else fails, I could visit your class with my Linux computer with the OpenMoko and QEMU stuff already set up. (I should probably do an update and make sure this still works.) Michael * I know that the phrase it should just work is no guarantee that it will. On Mon, 18 Jun 2007, Sameer Verma wrote: Does anyone have pointers on virtualization of openMoko via a VMWare-type setup? I'd like to see if there is something available so that I can do a quick demo for my class. I did the same with OLPC's virtual image (http://wiki.laptop.org/go/Using_QEMU_on_Windows_XP) and that worked wonders for students in understanding the value of such a project. A picture being worth a lot more, etc. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http: //verma.sfsu.edu/ http: //opensource.sfsu.edu/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
You *could* do what many existing linux apps do... write the functional part of the app as a console program, and then use many simple GUIs as options to interface with it. Think about cdrecord and K3b as an example. For the handful of us out there that intend to use the Neo as a remote administration device, being able to boot the thing into a GUI-less console mode (using bluetooth HID for input) would be a killer app as far as I can see. I use a full blown GUI desktop for most of my day-to-day stuff (KDE), but when I really want to get a bunch of remote-admin or compiling done, I just boot into run level 3, since I'd be in a terminal window anyway. Why waste the CPU cycles, especially on such a constricted CPU. If someone really wanted to keep things lightweight, you could even do a curses based interface as an option. 31337 HaXoRs and their console based phones. ~Bradley Florent THIERY wrote: I would say, considering the fact that the apps ecosystem hasn't flourished yet, is it really too late to switch? In the rest of this mail, please assume it is not. How detached is the underlying processes/functions and GUI from each other? How difficult will it be to just pull a different GUI layer on top of the phone functions? The openmoko team can choose among technos that separate the two layers. If you choose to develop (local) web applications for instance, then only the backend of the web rendering engine is the criteria. Switching from gdk to qt libs (which have had lots of embedded-oriented optimizations) will require only changing the rendering engine (webkit-gdk or webkit-qt), the backend isn't a concern. Yet, for traditional applications... If you choose to develop your applications using a general purpose scripting language (python/ruby/whatever), using GUI bindings that support multiple backends (such as [1] [2] ) could let time for the final decision... The clutter toolkit seems more and more interesting, because it supports: * GTK+ embedding * Language bindings for Perl and Python * Provides a fixed-point API [4] But it would also mean: * no apps before P2 model * no clutter-based openmoko devices on non-OpenGL-capable devices [1] http://wiki.python.org/moin/AnyGui [2] http://wiki.python.org/moin/Ocean [3] http://cairographics.org/backends/ [4]http://www.clutter-project.org/docs/clutter-clutter-fixed.html Any thoughts? Florent ___ 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: Asus Eee - interesting companion for the Neo1973
A bluetooth frogpad will likely be my means of text input (when I need to do a bunch), but the Eee looks interesting for other uses. ~Bradley Sven Neuhaus wrote: Interesting device: http://www.linuxdevices.com/news/NS9292516116.html http://www.asus.com/news_show.aspx?id=7317 It's dirt cheap and it looks like a nice companion to the Neo1973 to have a keyboard for text input and a larger screen. You need a GTA02 unit so they can communicate via WLAN, looks like the Eee-PC won't have Bluetooth. -Sven ___ 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: [SVHMPC] concept phone with only a touchscreen for UI
A possible solution for this has been discussed under an accessibility thread. The Maestro is a simple (yet effective) clip-on cover for PocketPCs. There are a few different versions of it, which work with various different brands and models of PocketPCs. Check out a picture at: http://www.engadget.com/2004/07/01/the-maestro-visuaides-pocket-pc-for-the-blind/ The device is simply real buttons that, when pressed, place pressure on a specific portion of the underlaying touchscreen. Real tactile feedback without any hardware modifications to the underlaying device. A software UI written to coincide with the specific button pattern is the only thing needed. You also get the advantage of very specific pressure points, allowing you to cram more hot areas into the UI than when using direct finger input. Now, what would be novel and cool for the Neo is if we could design a clip-on device that was also mostly (or completely) transparent, so the screen could be visible while still providing the tactile interface. Keeping some of the various disabilities in mind while designing the Neo OpenMoko could really make it a hit in this sector. Pretty much every phone solution out there for the blind is a real hack job, a system capable of catering directly to these folks would be welcome. (FYI, I work at a school for the blind). ~Bradley Chris Palmer wrote: Interesting ideas, but I'm not sure that any adequately handle the tactile needs of a touch typist. Without looking at the keys, I can feel the nubs on the home keys on my phone's mini qwerty to get lined up again. I also have the same concern with using a laser projected keyboard (even tho potentially high on the coolness scale). With just a big flat surface then there's no way to keep you lined up on your keys at speed. I type pretty fast on my mini qwerty. All my personal email for the last few years have been 99.9% written on this thing, including this one. -Chris On Sat, 2 Jun 2007 2:10 pm, Jon Phillips wrote: On Sat, 2007-06-02 at 13:35 -0700, Matthew S. Hamrick wrote: Well... for a while I was thinking about implanting a strong magnet under the skin in one of my fingers to detect alternating current. There are a few people out there who have done this and they say they can feel a very mild wiggle when the magnet comes near a wire carrying AC. It might be possible to detect the current going through the touchscreen as you make contact with it. But that's probably not a mainstream solution. That sounds like a stelarc solution: http://en.wikipedia.org/wiki/Stelarc What about a glove or thimble that you could put on your finger? How much does vibration tech. kill the battery on phones? Some type of current detection sounds interesting... Jon On Jun 2, 2007, at 1:11 PM, Jon Phillips wrote: Yes, it seems pretty clear that screens are the way forward rather than moving parts. I've seen a few solutions to the tactile feedback issue, with the main being have the phone vibrate slightly upon key press, along with sounds. Matthew (and others), have you heard of others? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Fwd: Re: Neo1973 Update!]
I imagine some creative programmer could offload some GPS calculations into 3D space... just an idea if the GPU is very efficient. ~Bradley Attila Csipa wrote: On Monday 04 June 2007 11:03, Florent THIERY wrote: My guess is that the primary application of that chip will be audio/video reproduction, and perhaps some blitting improvements, the 3D part is just bonus/eyecandy material. I do not agree with you: the neo currently struggles with 2D drawing; a real (understand: usable) zooming user interface has to achieve fluid un/zooming, so that the zooming metaphor applies to our Most of the time blitting = 2D :) But seriously, even window zooming isn't real 3D, and I'm not sure that you want an extra chip there just for aqua/beryl-like eyecandy. Of course, if you already have that chip there for other reasons, like image processing, H264, hardware MP3/AAC and blitting) it wont hurt to add some extra coolness :) ___ 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: Phone Call Security
Since all of the communications of a cell phone are digital (nothing is analog between mic and speaker), encrypting the voice data stream should be rather trivial (at least is in my understanding of the universe), even if you have to resort to implementing a virtual mic device that emits an encrypted sound stream. As I understand it, the hard part is doing key exchange, because for effective fast encryption you frequently swap out mid-sized symmetric keys that are traded using asymmetric encryption (right? correct me if I'm wrong). Since you can't easily do this over the voice channel, and you can't reliably fit the voice over the data channel, and you can't have both active simultaneously (or even intermittently), then you have a problem. But what about the recently announced wifi capabilities of P2 phones? This could make encrypted calls possible, and has an added security bonus. In secure VoIP setups, we have authentication, key exchange, and voice stream which are all sent over the same carrier. If you use the wifi capabilities of the Neo, then you have authentication and key exchange (wifi) done out-of-band from the voice stream (GSM). This means that when the bad guys are some government, they have to tap two entirely different and separate networks to have even a remote chance of knowing what all you are communicating (let alone actually decrypting it). The latency of the encryption, as long as it can be kept under about .5 seconds, really isn't all that noticeable in practice. Try calling a land-line from a cell phone in the same room, and you will usually notice anywhere from a .25 to 1.5 second delay. I've had cell phone to cell phone calls that exceeded a 2 second delay, and the effect wasn't even noticeable until the two of us are in the same room. If someone INSISTS on a secure line, an added .5 second delay will hardly be a concern considering the advantages. Just my two cents. ~Bradley Matthew S. Hamrick wrote: Encrypted voice calls is a question that's been around for a while. When I worked for RSA and later Certicom, we had frequent discussions about the strength (or lack thereof) of the LFSR-based encryption that was then in frequent use in GSM phones. I should probably mention that GSM and CDMA provide over the air authentication and confidentiality services. So if you're worried about bad guys cloning or eavesdropping on your phone calls (or text messages), you're safe already. Now... if your definition of bad guys includes the people who have operational control over the GSM network, then the story gets a little more complicated. Now, before you start saying, oh, Matt's just being paranoid or oh, Matt's going to say something that will help the terrorists, let me just remind you that outside the US, there's some pretty clear evidence that national governments are eavesdropping on the conversations of traveling tech company executives and passing economic intelligence along to competing companies in their own nations. So end-to-end encryption is an issue that's near and dear not only to the hearts of the bleeding heart liberals at the EFF, but also the uber-industrialists of the far right. End to end security is the term used to describe confidentiality and origin integrity services that provide assurance that the two endpoints in a communication are a) really talking to the person they think they're talking to, and b) the content of the call is not being intercepted by a malicious eavesdropper. This is distinct from the existing GSM security services which protect only the over the air portion of the comm link. Approaches to end to end security on GSM phones started with layering voice data over the GSM data channel. There are some significant issues with this approach. First is obviously that you've got to have a phone that can be programmed to channel encrypted voice data across the GSM data channel. But, this message is going out to a community that groks this concept, so the only thing I'll say is... if we do something like this, let's fully specify what we do so people working on other programmable phones can interoperate with us. Next is the issue of carrier support. I don't know if it's still an issue, but in the olden days it seemed that Cingular required you to call them up and explicitly activate your GSM data line. Then at the end of the month, they would turn it off requiring you to call up and get it activated again. But that's less of an issue these days as we move into an era where we have EDGE now and HSDPA on the horizon. But... the issue of latency is important. The GSM data channel has terrible latency characteristics. Products like the CryptoPhone (http://cryptophone.de/ ) suffer from this. If your latency is too high, the delay makes a normal conversation virtually impossible. You wind up having to say over after each thing you say to tell the other person it's okay for them to speak. This is okay if
Re: accelerometer in neo?
Does this mean we can solder one of these in and turn our moko into an enhanced Wii remote? :P ~Bradley [EMAIL PROTECTED] wrote: It was ~$14. Dirt cheap for what it does. If what people say about wasted space inside the neo is true then I'm hoping to cram one in there when I get my phone. Maybe some mems rate sensors too. Now that's _my_ kind of augmented GPS! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
Myk Melez wrote: David Ford wrote: Even with tuning, FF is a dastard piggy. I've tested things with FF. Start it with no history, no recovered session. Load up digg.com and do nothing. Just let it sit there. It will sit there and slowly grow and grow and grow. The caching isn't the problem, that's tunable. The problem is the memory leaks -- all the valgrind reports turned into moz teams (and ignored). I tried this over the weekend, creating a fresh profile for Firefox, starting it up, loading digg.com into it, and then letting it sit for a day. Memory consumption stayed constant. I'm using the latest nightly version of Firefox 2.0 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070513 BonEcho/2.0.0.4pre) on Ubuntu Linux 6.10. -myk ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I also tried doing this, but I got mixed results. Firefox 2.0.0.2, minus all the extensions and themes, would have consistent memory use sometimes, but not always. I did notice, however, that I could only get the memory to start leaking when using certain sites, digg being the primary one. The rate of the leak was quite substantial, and I imagine that the site's scripting or embedded flash/media content may be at least partially responsible. I had honestly never used digg before this test, and all of the other sites I use (like google, slashdot, wikipedia, and many others) have never caused me problems when leaving them open for days. However, this discussion is entirely off-topic at this point. The mainstream x86 FF release is not in any way a suitable candidate for the openmoko. The neo uses a different architecture. If a derivation or port of FF/Mozilla code is used on the neo, then an existing memory leak is of little concern - it's open source, submit a patch. ~Bradley ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Ian Stirling wrote: Werner Almesberger wrote: And no, I don't think we want to get into DRM ;-) I really think you do. No, you don't. OPEN-Moko. You start throwing any sort of DRM in these things and you will lose much of the community support that the moko needs. I want to be able to give this phone to my (hypothetical) employees. I do not want skilled lazy, employees able to - for example - edit their GPS logs which corroberate the inspections they are required to do. If they are skilled, then they are going to be able to circumvent any kind of protection measures you put in place. Tip: get better hypothetical employees. This is _not_ DRM that stops the owner of the phone doing stuff. Any DRM hampers the owner from doing want they want. No DRM can stop the owner, there is always a way around it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
While FF does have a fairly large footprint, I've never had these kinds of memory consumption problems. I generally leave my FF sessions open for days or weeks at home, and I simultaneously load 3D games, OOo, graphics apps, and other stuff without ever having trouble with memory (granted I do have 2GB). However, even the large memory footprint that I do see has an explanation, and can be tuned by tweaking about:config. By default, FF caches every page loaded on every tab for that sessions. If you consider a geek's multi-day surfing session, that is a lot of data to cache, and the cache data also can't be compressed. Since the primary target of FF is the average user -- which has several short surfing sessions and usually closes the browser between sessions -- the default settings make sense. If this is not your surfing style, then change your settings. That said, the full blown browser would be an awfully hefty app to put on a phone, and the minimo browser is currently targeting windows portables. Why not go with something with a tiny footprint, time-tested and proven lynx anyone? ~Bradley David Ford wrote: It behaves far better on my laptop as well, I strongly suspect it has something to do with the 64bit nature of my desktop vs 32 for all other places I use it. My 64bit firefox is currently taking 1.8G of ram after having been started ~16 hours ago. Several groups of people, myself included, have submitted valgrind outputs that show massive memory hemorrhaging but the reports pretty much get ignored. :( More debug tools would go a long way towards letting the community find and fix these issues and make FF something desirable on the neo. I love the idea of the neo, but it's just too small in cpu/ram for some other (really neat) ideas. I'm impatient :D -david Ian Stirling wrote: David Ford wrote: If it's anything like mozilla/firefox now, we're gonna need a hefty battery, hugely more cpu, and about 1G of ram onboard. Oddly. It seems to behave OK on my laptop - 1.5 - which I was using for some time with 128M RAM. Admittedly, it did need restarted every day or three. The big problem is the lack of debug tools. I write a new extension. I then want to profile it, to find out how much CPU, and how much CPU it makes the core use. I can't. Worse, the same problem applies to most of the XUL/XBL/JS core. ___ 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: Blacklist/whitelists
Jonathon Suggs wrote: Tim Newsom wrote: That seems weird... Even in email you can turn off read receipts... It seems like an invasion of sort (though a minor one) to not allow disabling of delivery reports for the receiving party. If the sending party can enable it and the receivers phone automatically responds, then you can always know when someones phone is turned on/available. Does the sms message system work while the phone is in call mode? Does that require multiplex code also like the gprs while on a call does? If it doesn't work while calling, you can always find out when someone is done talking on the phone / is available to talk (assuming they are at the phone) by sending an sms with delivery report first... Right? Seems like there should be some kind of control message that could be sent over the serial port via 'AT' commands which would enable and disable this. --Tim Ok, I'll be honest that I have no proof that this is how it actually works, but I don't think it works the way you are saying it does. Again, not 100% positive, but the receipt that you receive is only a message that it has been successfully transfered to the carrier. The carrier will then try to push the SMS to the recipient whenever they become available. So there are two discreet actions. 1) Transfer from sender to carrier 2) Transfer from carrier to destination. Rather than get all worried about big brother, just do a simple test. Turn off a phone and send a text message to it. See if you get a receipt. If you do, then I'm right. If you don't get a receipt until the phone you sent a text message to is turned back on THEN commence the meetings of the tin foil hat club. -Jonathon SMS most likely uses a mechanism similar (or identical) to the ESMTP DSN model. See http://tools.ietf.org/html/rfc3461 for more info. With cell phones, it seems that the destination storage medium for the message server is the phone itself. The phones probably don't get any headers on the message in advance of accepting the message, so there is probably no way to reject messages on a per-sender basis, at least not in a way that avoids being charged for message delivery. As long as Ma Bell controls the message servers, we probably wont have a way around this. You could probably implement a Reject All feature by simply refusing to accept transmission of SMS messages. This may be desirable for people that don't like receiving text messages at all (i.e., me). ~Bradley ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
Knight Walker wrote: On Fri, Apr 06, 2007 at 10:31:47AM -0700, Tim Newsom wrote: That seems weird... Even in email you can turn off read receipts... It seems like an invasion of sort (though a minor one) to not allow disabling of delivery reports for the receiving party. There are two kinds of delivery reports, Delivery Status Notifications (network generated) and Return Receipts (client generated) are two very different things indeed. ~Bradley ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Multi-Touch
I personally like the configuration of my synaptics touch pad. I have left, middle, and right clicks (1, 2, and 3 finger tapping, respectively), and I can also use the right and bottom edges for vertical and horizontal scrolling. However, keep in mind that touch *screens* are very different in design than touch *pads*. With a touch screen, the cursor moves to the coordinates of the pressure. With a touch pad, the cursor does not move based solely on pressure being applied. Instead, touch pads track the motion of the pressure point and move the cursor in the appropriate direction and speed. Mixing and matching the capabilities of these may be more difficult than we think, not just from a hardware/driver point of view, but also in user-friendliness. ~Bradley Florent THIERY wrote: Last post, promise :) I found this: http://iscroll2.sourceforge.net/ iScroll2 is a modified trackpad driver that adds two-finger scrolling capabilities to supported pre-2005 PowerBooks and iBooks on OS X 10.3 and up. To scroll, just place two fingers on your trackpad instead of one. Both fingers need to be placed next to each other horizontally (*not* vertically, the trackpad cannot detect that). Some people get better results with their finger spaced a little bit apart, while others prefer having the fingers right next to each other. iScroll2 provides two *scrolling modes*: Linear and circular scrolling. For *linear scrolling*, move the two fingers up/down or left/right in a straight line, respectively, to scroll in that direction. *Circular scrolling* works in a way similar to the iPod's scroll wheel: Move the two fingers in a circle to scroll up or down, depending on whether you move in a clockwise or counterclockwise direction. Added here: http://wiki.openmoko.org/wiki/UI_Improvements#Extending_the_touchscreen_capabilities_and_input_methods Cheers And good night Florent ___ 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: Voice synthesizer for blind and visual impaired person
I work at the Kansas School for the Blind. Portable computing devices for the visually impaired are extremely expensive, so seeing an affordable OpenMoko device that is blind-friendly would be great. Personally, I am interested in OpenMoko because I think using a phone for remote administration of my Linux servers would be convenient. But, I'd be more than interested in connecting developers with the experts I know in the field of disability accommodations. As for making touch-screen devices accessible, take a look at the Maestro, which has a clip-on cover for Dell Axim PocketPCs. You can see a picture of the device at http://www.humanware.ca/web/en/p_DA_Maestro.asp#content A similar clip-on device would be ideal in the case of OpenMoko. Obviously, if the UI were designed with such a cover in mind, then implementation of the cover device would be much easier. ~Bradley adrian cockcroft wrote: There are a lot of people who can't read the tiny fonts on their phone screen. I'm particularly interested in making a UI variant that is optimized for people with failing eyesight, but not completely blind. I have a friend with macular degeneration who wants me to make a phone she can use, and many older people just get long sighted and want a simple UI they can actually read. For completely blind people we could make a voice driven UI using VoiceXML to specify the flows. I work alongside someone who has done VXML work using Tellme's backend service. I'm not sure if there are implementations we could use on the phone itself. Adrian On 3/27/07, Gabriel Ambuehl [EMAIL PROTECTED] wrote: On Tuesday 27 March 2007 10:23:08 Bartlomiej Zdanowski AutoGuard Ltd. wrote: There's so much to do for blind person and we can do it together so think guys and please provide some solutions and thoughts. I would imagine that a touchscreen only phone is quite hard to use for blind people as opposed to a phone with proper keys? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
