Re: OT: SIM contact limitations
Am 26.09.2009 um 01:46 schrieb Brolin Empey: Hello list, I am marking this message as OT because it is not specific to Openmoko, but I thought someone here may know because I think most members of this list are relatively technical. Anyway, why are SIM contacts (contacts stored on a SIM) so limited? Cannot have multiple phone numbers per contact. Cannot change the type (home, work, mobile, etc.) of the phone number. Names are truncated to 18 chars. Mainly, because SIM card entries have been standardized approx. 1992 so that you can use them in *any* phone. Back then, SIM flash memory and computing power of a phone was *very* limited. Less than a C64 :) It is similar to why plain old FAT memory card format is still in use with all its limitations. Why do I have to store contacts in the phone instead of on the SIM to do anything useful? Because you have much more memory and more flexible data formats. But you can't simply remove the SIM and place it in a historical phone like let's say a SIEMENS S4. Thanks, Brolin -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ ___ 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: Qi - why only 3 partitions on SD card?
Am 25.09.2009 um 21:27 schrieb Torfinn Ingolfsen: To a user, it might look like this: - U-boot wasn't working correctly with newer (bigger) kernels, so the developer(s) abandoned it - instead they created Qi to be newer, better, faster and so on - Qi isn't living up to promises for users I'm not saying that such a view is correct, but that is how it can look like from a users view. What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. And adding stateless boot from the rootfs would be nice to have in u- boot as well (for other hardware that uses u-boot). When looking into the most recent official u-boot sources I was disappointed to find essentially nothing from OM. Other open hardware projects like OpenPandora simply use mainstream u-boot. Maybe, the better path would have been to integrate more OM-u-boot back into official u-boot and work on the general limitations instead of starting a new project (Qi). But you can only influence the future but never change the history... -- hns ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Dr. H. Nikolaus Schaller wrote: What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. I'm just a bystander here, but from what I understood this wasn't the reason Qi was started. u-boot is an entire environment that needs drivers for a lot of the hardware (usb, graphics, pmu, etc.) all of which end up duplicated in the Linux kernel. The u-boot philosophy (of an entire environment supporting DFU and a boot menu) implies that those drivers have to be maintained in two places (u-boot and kernel) which cases pain, and inevitably results in u-boot being slower to boot. Qi starts with a completely different philosophy - that the bootlooder should do as little as possible, and that it should need to know as little as possible about the hardware. In terms of intent, it's closer to the coreboot project than it is to u-boot. You really couldn't achieve this [separation of bootloader device drivers] with u-boot, which is why the separate Qi project was formed instead of continuing to evolve u-boot. So what you _can't_ do inside Qi is have a graphical boot menu, or support dfu - because Qi doesn't know how to talk to the hardware. What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. There's a philosophical difference between the two projects, and I think Qi's approach is much better suited to this kind of hardware, than u-boot could ever be (with trunk, or with the existing gripes resolved). But you can only influence the future but never change the history... Wise words! :-) Imho our time would be better spent building this mini-environment (which would probably be best constructed in initrd as Paul mentioned) than returning to u-boot. Any takers? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Dr. H. Nikolaus Schaller h...@computer.org writes: To a user, it might look like this: - U-boot wasn't working correctly with newer (bigger) kernels, so the developer(s) abandoned it - instead they created Qi to be newer, better, faster and so on - Qi isn't living up to promises for users I'm not saying that such a view is correct, but that is how it can look like from a users view. What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. It didn't. Maybe, the better path would have been to integrate more OM-u-boot back into official u-boot and work on the general limitations instead of starting a new project (Qi). General limitation of u-boot is different ideology behind the project. Please take a look at coreboot[1] to understand what i mean. Also please see my other mail for additional information about why some developers think that u-boot is more hassle than win. [1] http://www.coreboot.org/FAQ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Am 26.09.2009 um 11:12 schrieb Nikita V. Youshchenko: What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. Have anybody done this, at least in proof-of-concept form? As far as I remember the good old Sharp Zaurus did it that way some years ago (unfortunately most links are gone). It loads a Mini-Linux that was the real bootloader and finally loaded the full Linux. If yes, any links? ___ 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: Qi - why only 3 partitions on SD card?
On Sat, 2009-09-26 at 09:06 +0200, Dr. H. Nikolaus Schaller wrote: Am 25.09.2009 um 21:27 schrieb Torfinn Ingolfsen: To a user, it might look like this: - U-boot wasn't working correctly with newer (bigger) kernels, so the developer(s) abandoned it - instead they created Qi to be newer, better, faster and so on - Qi isn't living up to promises for users I'm not saying that such a view is correct, but that is how it can look like from a users view. What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. And adding stateless boot from the rootfs would be nice to have in u- boot as well (for other hardware that uses u-boot). When looking into the most recent official u-boot sources I was disappointed to find essentially nothing from OM. Other open hardware projects like OpenPandora simply use mainstream u-boot. Maybe, the better path would have been to integrate more OM-u-boot back into official u-boot and work on the general limitations instead of starting a new project (Qi). But you can only influence the future but never change the history... -- hns u-boot can still work with bigger kernels - its part of the environment setup. There are instructions on the wiki somewhere. Ive just gone back to u-boot from Qi - cant stand the WSODS which only occur with Qi for me - makes the phone unusable as it usually does it on an incoming call. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
u-boot being slower to boot. Just FYI. I was involved in recent MontaVista's boot-in-one-second presentation. That demo did use u-boot (although somewhat changes) in the one-second boot process. Kernel got control there in about 0.3 seconds since poweron. So claim that u-boot is unable to do things fast is plain incorrect. signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner case + stylus holder (was Re: New case)
the fr was designed with the outspoken idea of finger friendliness, or rather, only to be operated by finger only. while the idea as such sounds appealing, for a lot of people it is not really the way to go: - as you said, stylus is far more precise - stylus allows more efficient use of screen real estate since active areas like buttons or icons can be much smaller - finger includes a lot of dirt on the screen, let alone dust which in turmn may cause scratches (more easy than a stylus at least) the quest for a stylus holder has accompanied the fr at least since the begin of mass deployment and there was some hope in the beginning, when everybody spoke of designing a new casing, someone would come up with a casing including a holder. so far, not a single case has shown up, thus no holder either. some people use a triangular stylus tied to the lanyard hole, which makes at least sure, the stylus is always there and doesn't get lost, maybe the wiki has some pictures and addresses, where to get those. additionally, i seem to recall that someone (concerning the lanyard hole) siad, the casing's design was made originally for some kind of device for the peking olympics, most likely not for a multipurpose device like the fr and far less for anything besides finger operation --- not sure, if that's correct, though. so, to make it short: - the missing holder is missing by design - the availability of the design files should enable everbody, who knows how to, to create its own design and, susbsequently, casing - maybe a successor/offspring of the gta-core project will address that ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Sat, Sep 26, 2009 at 10:36:54AM +0100, George Brooke wrote: There was a thread on the devel list see here: http://lists.openmoko.org/nabble.html#nabble-td1980163%7Ca1980163 That link isn't working, it just gives a nearly blank page. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. Have anybody done this, at least in proof-of-concept form? If yes, any links? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Sat, Sep 26, 2009 at 10:36:54AM +0100, George Brooke wrote: There was a thread on the devel list see here: http://lists.openmoko.org/nabble.html#nabble-td1980163%7Ca1980163 That link isn't working, it just gives a nearly blank page. It worked for me in Firefox, but not in konqueror. signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
Alternatively, use org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 and find a dhcp server running on the FR with everything else preconfigured. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Hi, On Sat, Sep 26, 2009 at 1:17 PM, Rask Ingemann Lambertsen ccc94...@vip.cybercity.dk wrote: On Sat, Sep 26, 2009 at 10:36:54AM +0100, George Brooke wrote: There was a thread on the devel list see here: http://lists.openmoko.org/nabble.html#nabble-td1980163%7Ca1980163 That link isn't working, it just gives a nearly blank page. FWIW, the link works for me (now). The subject of the thread is Touch based Dual Boot Menu. The thread is from March this year, it includes a couple of examples, one have a screenshot of a working menu. Still - nothing is published for users to try. -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Sat, Sep 26, 2009 at 11:12 AM, Nikita V. Youshchenko yo...@debian.orgwrote: What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. Have anybody done this, at least in proof-of-concept form? If yes, any links? Search kexecboot http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git;a=shortlog;h=refs/heads/cfgfiles I'm using it on my old Sharp Zaurus and it works great, still actively developed (would be nice to have some hacker testing, improving support for freerunner). I liked u-boot menu and this is even better as kernel for this and then whole system can be quite the same. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Am 26.09.2009 um 10:20 schrieb Dave Ball: Dr. H. Nikolaus Schaller wrote: What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. I'm just a bystander here, but from what I understood this wasn't the reason Qi was started. u-boot is an entire environment that needs drivers for a lot of the hardware (usb, graphics, pmu, etc.) all of which end up duplicated in the Linux kernel. The u-boot philosophy (of an entire environment supporting DFU and a boot menu) implies that those drivers have to be maintained in two places (u-boot and kernel) which cases pain, and I see. This is surely a problem. For u-boot there are estimatedly 200 other hardware projects around that have the same issue. Therfore porting fixing is only 1/200 of efforts. Except the hardware specific parts (e.g. LCD). inevitably results in u-boot being slower to boot. That one I do not really understand. If I want to load a kernel from MMC it needs the driver anyway. And why is it slower if there are other (unused) drivers available? The only delay I am aware of for u-boot is from waiting if someone wants to break into command line mode through the console... Otherwise the boot speed should only be limited by how fast we can locate and fetch the kernel image from peripheral memory. Qi starts with a completely different philosophy - that the bootlooder should do as little as possible, and that it should need to know as little as possible about the hardware. In terms of intent, it's closer to the coreboot project than it is to u-boot. You really couldn't achieve this [separation of bootloader device drivers] with u-boot, which is why the separate Qi project was formed instead of continuing to evolve u-boot. But u-boot evolves anyway (with us or without) because many other projects simply use it. Nevertheless your point with the LCD device driver is very valid. It is specific to every piece of hardware. Only the CPU is more generic. So what you _can't_ do inside Qi is have a graphical boot menu, or support dfu - because Qi doesn't know how to talk to the hardware. What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. Isn't this even slower than u-boot? There's a philosophical difference between the two projects, and I think Qi's approach is much better suited to this kind of hardware, than u-boot could ever be (with trunk, or with the existing gripes resolved). Hm. This makes me raise some questions: * what is so specific with this hardware so that Qi is better suited? * is there any indication that Qi is adopted by other hardware projects? But you can only influence the future but never change the history... Wise words! :-) Imho our time would be better spent building this mini-environment (which would probably be best constructed in initrd as Paul mentioned) than returning to u-boot. Any takers? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] fsoraw no effect?
following the wiki i started navit with fsoraw -r Display,CPU navit nevertheless, the display went blank after the idle timeout defined in frameworkd.conf. Could you please do two simple things: *) check the state of FSO resources while running the above command. This may be done with mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState Display mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState CPU *) check what happens if you manually set resource policies for Display and CPU to 'enabled' mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display enabled mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display enabled Will display blank then? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all/fso?] external battery just mobile gum pro woes
On Fri, Sep 25, 2009 at 06:59:18PM +0200, arne anka wrote: Did you set USB charge current to 500mA? If device which you are connecting can't ennumerate USB connection, Neo will charge with only 100mA No, it will try to charge with 1000 mA. This is a bug. well, didn't here, though the gum pro is capable of 1000mA output. Check your /var/log/kern.log or dmesg. You'll see messages saying something like 'pcf50633: Setting USB current limit to xyz mA'. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Auto home revision 1.1
Hi, +1 Definitely. The community can and does help. Use it. -- View this message in context: http://n2.nabble.com/Auto-home-revision-1-1-tp3698124p3717949.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
On Sat, Sep 26, 2009 at 04:23:24PM +0200, Sebastian Krzyszkowiak wrote: No, but if someone wants I can add it to my TODO for shr-settings. Yes, please :-) signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
On Sat, Sep 26, 2009 at 02:34:31PM +0100, Michael Lauer wrote: Alternatively, use org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 and find a dhcp server running on the FR with everything else preconfigured. Is this exposed anywhere by a GUI? Regards Jeff signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian/fso] fsoraw no effect?
following the wiki i started navit with fsoraw -r Display,CPU navit nevertheless, the display went blank after the idle timeout defined in frameworkd.conf. since the fr was connected via usb, it would not suspend, thus i don't know if at least requesting the cpu would have worked. simple questions: - are there any known issues with fsowraw? - is the way described in the wiki (http://wiki.openmoko.org/wiki/FSO_Resources) outdated? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
On 9/26/09, Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com wrote: On Sat, Sep 26, 2009 at 02:34:31PM +0100, Michael Lauer wrote: Alternatively, use org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 and find a dhcp server running on the FR with everything else preconfigured. Is this exposed anywhere by a GUI? Regards Jeff No, but if someone wants I can add it to my TODO for shr-settings. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Offline SHR Manager - First Release 0.1
Hey, Very nice - I'll play with this as soon as I can. -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Mokomaze and incoming call
Hi! Although I love Mokomaze, its just addictive, could it be modified in a way, when an incoming call happens, it stops itself (like when you touch on the screen), to prevent CPU abuse? What happened to me: Mokomaze was running when incoming call happened, the call screen came up way longer then usual (ie. about 3 sec), and when I hit the accept button it could not accept the call, and the vibrator just rerun for a few ms in every sec or two sec. Really strange. Then the other party hang up. Mokomaze, came back, I stopped it, and recalled the guy who called me. So it was really a minor annoying issue, but it costed me 1 min of call;-) And btw, what happened with the mokomaze's dreams like: * 2 player mode (I play, then i pass to her to play, then I play again) * number of lives * some score system * some cheetings * enemy ball or teleport doors or having multiple balls when you hit a magic hole, just like what flippers do. Calm me, that the development didnt stopped ...;) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner case + stylus holder (was Re: New case)
On Sat, Sep 26, 2009 at 11:06 AM, arne anka openm...@ginguppin.de wrote: so, to make it short: - the missing holder is missing by design - the availability of the design files should enable everbody, who knows how to, to create its own design and, susbsequently, casing - maybe a successor/offspring of the gta-core project will address that Yes missing stylus holder is one of biggest issues for freerunner from my POV :(. O bought few small styluses (originaly for nintendo or something) and attached sort of stylus holder on one side of original pouch (2 short rubber tubes tied to it with wire through pouch perforations). And I feel always ashamed of this, with so nice neo phone! I would like to see transparent neo case with integrated stylus holder :). Open from all POVs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - QX - Unable to connect to X server
More info: (now running QtMoko v11) I had the Unable to connect to X server message again. This time I looked around (via ssh) and found out that the file /tmp/.X0-lock existed. Interesting. I did rm /tmp/.X0-lock And this time I could start QX. Very interesting. -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Sat, Sep 26, 2009 at 12:00:46AM +0400, Paul Fertser wrote: Qi was created to have a minimal simple easily maintainable bootloader, take a look at coreboot project to understand the idea behind Qi. U-boot is just wrong for this kind of device: it's neverending porting of Linux drivers to u-boot which doesn't make much sense when you can boot Linux, the kernel directly. So why doesn't Qi do that? Qi also has drivers for PMU, NAND flash, SD card, file systems, etc. Why not boot a kernel directly? Lack of menu with initramfs says imho that nobody really needs it or else it would have been created long time ago. No, months ago I made a trimmed down kernel for the purpose and would have given the initramfs menu a shot months ago if only the required kexec() interface was documented somewhere. Since it isn't, I'm stuck with U-Boot, which to me isn't really all that bad. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - QX - Unable to connect to X server
On Sat, Sep 26, 2009 at 3:46 PM, Torfinn Ingolfsen tin...@gmail.com wrote: More info: (now running QtMoko v11) I had the Unable to connect to X server message again. This time I looked around (via ssh) and found out that the file /tmp/.X0-lock existed. Interesting. I did rm /tmp/.X0-lock And this time I could start QX. Very interesting. It seems that if I always remember to stop TangoGPS when I am back in QX after a AUX keypress, everything works as expected (the lock file is removed, and I can start TangoGPS again. Cool. -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Offline SHR Manager - First Release 0.1
Offline SHR Manager (oSHyReMan) is a tiny GTK-based tool for managing your Freerunner from your Desktop when the phone is connected via USB. The idea behind is putting together a collection of commands, which are executed via SSH - before oSHyReMan again and again typed by the user - now with oSHyReMan automatically. Currently, you can: - Make backups of important files / restore files from backups - Manage your GPS (tangoGPS) tracks (e.g. import GPX etc.) - Edit comfortably configuration files using an Editor of your choice On top, system information is displayed on front page. You can get a copy here (Ubuntu deb or Sources): https://projects.openmoko.org/frs/?group_id=303 For getting started, have a look on the wiki: https://projects.openmoko.org/plugins/wiki/index.php?id=303type=g I have put some screenshots here: http://www.kichkasch.de/oshyreman/screenshots/slide_1.html I would be thankful about feedback - especially any input for further developments, e.g.: - which files should be included in a backup by default - which configuration files are worth to be included by default - which system information parameters are of interested (and how can we obtain them) Enjoy playing with it, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Saturday 26 September 2009 10:12:59 Nikita V. Youshchenko wrote: What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. Have anybody done this, at least in proof-of-concept form? If yes, any links? There was a thread on the devel list see here: http://lists.openmoko.org/nabble.html#nabble-td1980163%7Ca1980163 solar.george signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Dave Ball openm...@underhand.org writes: ... There's a philosophical difference between the two projects, and I think Qi's approach is much better suited to this kind of hardware, than u-boot could ever be (with trunk, or with the existing gripes resolved). Great thanks for this clear and complete explanation. I hope that they'll finally get it after your write-up. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner case + stylus holder (was Re: New case)
On Sat, Sep 26, 2009 at 2:50 AM, Brolin Empey bro...@brolin.be wrote: but lacks a stylus holder. I use my freerunner as my (only) cell phone and I spent additional time just for hacking on it, so I use it extensively. I bought a leather case with my freerunner from tuxbrain, and it protects the freerunner, and has a stylus holder too. My freerunner felt more then 20 times already (even from the first floor*), but thanks to this case, there is no damage at all... (I also have screen protector which is an absolute musthave). *:I also had an accident with my electric bike, and the leather case damaged quite a lot (the metal clip has no longer leather on it;), but the feerunner survived without a scratch, just the leather case, the bike, my pants and t-shirt damaged. So I recommend a case, which has a stylus holder builtin. Also it is a good idea, to protect your freerunner by the way. Just my 2 cents. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Offline SHR Manager - First Release 0.1
On 9/26/09, Baruch Even bar...@ev-en.org wrote: Hi, Michael Pilgermann wrote: Offline SHR Manager (oSHyReMan) is a tiny GTK-based tool for managing your Freerunner from your Desktop when the phone is connected via USB. The idea behind is putting together a collection of commands, which are executed via SSH - before oSHyReMan again and again typed by the user - now with oSHyReMan automatically. I'm been thinking about a similar thing but maybe a better approach is to have a small webserver on the moko with a cgi that presents a web interface to the user with plugins from various applications that help you manage them, configure them and do whatever is needed. This way it will work no matter what your host is, it can also work when at a friends/parents and not depend on your machine. As convenience improvements that I'd like for such a solution would be to register this webapp with avahi for zeroconf detection and an export of a small usb drive with windows/mac/Linux drivers/conf that can make configuring the network on the moko a breeze. I already have some code that uses libsoup for a basic webserver in vala but I'm also doing other things as well and don't have enough time to work on this all by myself, if there will be collaborators I'd be happy to jump-start such a project. Any takers? Baruch ___ Shr-User mailing list shr-u...@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-user Ping mrmoku on #openmoko-cdevel to create git repo for you at git.shr-project.org. Please! :) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Offline SHR Manager - First Release 0.1
Hi, Michael Pilgermann wrote: Offline SHR Manager (oSHyReMan) is a tiny GTK-based tool for managing your Freerunner from your Desktop when the phone is connected via USB. The idea behind is putting together a collection of commands, which are executed via SSH - before oSHyReMan again and again typed by the user - now with oSHyReMan automatically. I'm been thinking about a similar thing but maybe a better approach is to have a small webserver on the moko with a cgi that presents a web interface to the user with plugins from various applications that help you manage them, configure them and do whatever is needed. This way it will work no matter what your host is, it can also work when at a friends/parents and not depend on your machine. As convenience improvements that I'd like for such a solution would be to register this webapp with avahi for zeroconf detection and an export of a small usb drive with windows/mac/Linux drivers/conf that can make configuring the network on the moko a breeze. I already have some code that uses libsoup for a basic webserver in vala but I'm also doing other things as well and don't have enough time to work on this all by myself, if there will be collaborators I'd be happy to jump-start such a project. Any takers? Baruch ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner case + stylus holder (was Re: New case)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.09.2009 19:13, Laszlo KREKACS schrieb: I bought a leather case with my freerunner from tuxbrain, and it protects the freerunner, and has a stylus holder too. My freerunner felt more then 20 times already (even from the first floor*), but thanks to this case, there is no damage at all... I second this. I bought the same case [1] and I am 100 percent satisfied. Same story basically: Freerunner has been dropped a few times - - no damage. Also: better protection from dust and dirt. And a small stylus is even included with the case :) If you want a stylus with you at all times and can live with the thought of keeping the freerunner clipped to your belt - you should definitely buy this case! Regards, Andreas [1] http://www.tuxbrain.com/en/omcase.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq+asYACgkQ5Fl7TYZQYwEsswCfUe2Fz5AUUQpOOMDde/rvVyJq M/4AoI3Z9joGy6adUo2lR9SGYEXjYEYA =pue7 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner case + stylus holder (was Re: New case)
2009/9/26 Andreas Cyberfrag Fischer cyberf...@gmx.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.09.2009 19:13, Laszlo KREKACS schrieb: I bought a leather case with my freerunner from tuxbrain, and it protects the freerunner, and has a stylus holder too. My freerunner felt more then 20 times already (even from the first floor*), but thanks to this case, there is no damage at all... I second this. I bought the same case [1] and I am 100 percent satisfied. Same story basically: Freerunner has been dropped a few times - - no damage. Also: better protection from dust and dirt. And a small stylus is even included with the case :) If you want a stylus with you at all times and can live with the thought of keeping the freerunner clipped to your belt - you should definitely buy this case! Regards, Andreas [1] http://www.tuxbrain.com/en/omcase.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq+asYACgkQ5Fl7TYZQYwEsswCfUe2Fz5AUUQpOOMDde/rvVyJq M/4AoI3Z9joGy6adUo2lR9SGYEXjYEYA =pue7 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Happy to see people happy with the leather case :), just one point now the case has full loops in addition of the belt clip , for use when you need even more secured tight to you. Example zones with a lot of friends of things from others :P regards -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko application showroom status
2009/9/21 Risto H. Kurppa ri...@kurppa.fi: Wow, great to see this, thanks David!! I'm sure the filtering thing makes our life a lot easier! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi om-showroom apt-portal app has started :) Nothing is online yet and if you test in local will see a a messy mixture of a om-showroom and playdeb but is a start anyway :P Regards -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
CONFIG_ANDROID_LOW_MEMORY_KILLER troubles
Hi, we had quite big troubles with andy-tracking kernels that have CONFIG_ANDROID_LOW_MEMORY_KILLER option enabled. This kernel keeps killing processes and prevents using swap space. This option was added to support android, but it seems that it prevents any other distributions to work correctly when memory is getting low. This was tested with QtMoko v11 (which uses the same kernel as SHR btw). After i had disabled this option (with other android stuff) the problems went away. Any ideas how to solve this problem? In QtMoko we can disable this option but kernels for other distros should be fixed too. Credits to Jim Morris who tracked down this problem. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
