Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
What music applications would you be sharing? -nick Jay Vaughan wrote: I thought the Openmoko developer community would want to better than that ... Whats missing IMHO is a Repository Leadership clique, wherein a known group of people are responsible for some nice repositories that end-users might find interesting .. If I could easily add a few sites to my Freerunner, I would. And I'd watch them for regular updates too. For example, I'm considering firing up an Openmoko repository - known and public - for music apps for the OpenMoko suite .. ; -- Jay Vaughan ___ 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: using the openmoko neo101 in mass storage mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Fri, May 30, 2008 at 11:53:29AM -0700, Matt Mets wrote: | I believe this has been discussed at some point, but there is a | file-storage module that emulates a mass storage device: | http://www.linux-usb.org/gadget/file_storage.html | | I don't see it included in the preview ASU package, but it should be | trivial to build separately. | | The issue (that I see, anyway) is that it requires exclusive access to | the drive that it uses for the storage. | | I think we could get around with pretending to be a digital camera / media | player instead. IIRC the protocol prefered by windows for these is more | like a file server protocol (i.e. commands at file level) although maybe | windows doesn't allow to download files from media players and may not | allow to upload on cameras. | But that should get around the exclusive access problem. | | Also there could be an image file which is shared via USB storage so no | need to unmount the SD card. That is true, Joerg also mentioned a separate partition which works as well. Each requires a fixed allocation of storage from the medium but it isn't death. The thing that bothers me is the effective requirement to force unmount the filesystem either way. It's for sure you wanted that filesystem mounted in the device when it isn't presented as mass storage gadget, so it limits you to scenarios where you never hold the files in there open long term. So media playing or camera kind of usage would be OK as we are familiar with from mp3 players as mass storage, but there are many other kinds of access that hold a handle open on the file long term, eg, database file. Especially when it's your /home that is getting shared, on a Linux box you might have a few painful bleeding stumps if you plugged it in and forced umount (which some folk anyway deliver by looking in lsof -n | grep mountpoint and killing everything). Another side of it is I use the GTA02 tethered by USB cable to a host for power and Ethernet-over-USB access, if I used the mass storage gadget as well then I would likely not want the modal behaviour that my storage filesystem is forced unmounted the whole while I am hooked to the host. I would transfer files and then want to do something with the files during a session. These objections don't really kill mass storage gadget as something to consider, but sharing a filesystem at the network layer just doesn't have these problems and acts like we are used to in normal Linux usage. ~ It's annoying that basically Windows will drive us to decide which way to jump or if to implement both, but there we are. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGNkcACgkQOjLpvpq7dMqVGgCgj7Wy6LD876ZswAC9v5dY7sUx jgEAoIQu908bvFh+JV2YPV2BxyY07+Tm =3H8q -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Rod Whitby wrote: | And therein starts the decline of Openmoko application availability into | the poor practices of the windows world ... | | ;-) It's really two different usage scenarios: one is the nice and tidy | distribution, the other is getting something to build and, sometimes, | to disseminate it quickly. | | While there are people who indeed have the angelic patience to work in | distribution mode all the time, for most of us, this is just too much | pain and overhead. (Hi Andy ;-) Hi yourself... I guess you must have started using Openmoko build system then because last time we spoke about it you were avoiding it same as me - -- for the same reasons. | Also, having a toolchain that makes it easy to cross-build from sources | will help a lot towards people not even wanting to download pre-built | binaries. This is completely backwards. I know you run Gentoo so maybe the insanity is normal for you, but if someone painstakingly equipped their box to build death-foo-libs package that has crazy build dependencies on automake 0.1 and emacs 0.01, and kindly packaged and made available the binary, why on earth should you ignore that and go through agonies setting up your box to regenerate exactly the same bits? They even give you a -dev package, after YOU compiled the thing there is NOTHING additional over just using the packages. Except what, a chunk of your life evaporated while you stared at things scrolling. What you should have said is: ''Also, having a toolchain that makes it easy to cross-build from PACKAGES will help a lot towards people not even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGOH8ACgkQOjLpvpq7dMpdEwCglPhYYa6ZK7zIR7GdKtXp3qpc zzwAn3JcIXJJj/SU8hcO/8U8cVfIzAhR =TJSV -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | in a main repository? In Fedora, the multitude of repositories for | downloading packages has caused nightmares of dependency hell when | users install from two or more repos that carry some of the same package. | | The most user-friendly solution is one location that holds all the apps | a user could want, one place for them to look, one place to maintain. | Branching repositories should be avoided as much as possible. | | Submitting packages to OE is like contributing upstream. It makes the | most out of your contribution. Yeah I know what you are talking about exactly. In fact it is OK if apps are in multiple repos so long as they are linked entirely against canonical dependent packages from central distribution. The damage came when you had say mplayer from freshrpms and livna that each required and imported say faad from their respective repositories. Then if you wanted xine from a different place you got mplayer, the Hell appeared because faad dependency in xine could either be satisfied by the foreign package of different patchlevel than the one from the same place as the Xine, or worse could not be satisfied due to use of = version dependency when the two repos' faad were at different versions. Of course it becomes political then what gets into the central distribution with what config options, as happened with Fedora rafts of dependent packages were landgrabbed into Extras as the de-facto canonical source of them and the independent guys felt treated badly about having that taken away from them rather brusquely. In addition people were and still are grumpy about the pretty intense packaging rules and bureaucracy surrounding submission of packages and approval, although since as a Fedora user I benefit from the high level of engineering and consistency I find it hard to argue against it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGOuwACgkQOjLpvpq7dMq2GQCeI9+3ZV3kn5nrmwDaHKJi4gG0 cM8Anj0U1lFpaM32+W4UuJLcM30kONzI =1GZi -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Andy Green wrote: Hi yourself... I guess you must have started using Openmoko build system then because last time we spoke about it you were avoiding it same as me - -- for the same reasons. I think you misunderstood me there - I wasn't referring to myself when I mentioned the angelic patience :-) (*) For me, bitbake is a great tool for distribution makers. I say that it's a great tool for them because they seem to be happy with it. When they're happy and make happy little pre-compiled packages for me, I'm happy as well. And I'm even happier if I never ever have to touch bitbake ;-) (*) If you must know, I was thinking of Raster. Although the deprecations he uttered on IRC while struggling to use bitbake as a twisted substitute for make seemed somewhat less angelic (-:C What you should have said is: ''Also, having a toolchain that makes it easy to cross-build from PACKAGES will help a lot towards people not even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' What I mean is that, with a good and extensible toolchain, you can pick some Openmoko-agnostic package and build it from sources without pain. Yes, if the package has already been properly openembeddified and is part of someone's build process, sure, you can just grab the binary. But often enough, you'll find that this hasn't happened yet, and you probably want to try it out before lobbying its addition to the daily build. Similarly, if it's work in progress, you often don't want to wait for the daily build. And neither do you want to run your own OE build just to get that package (unless you're blessed with the aforementioned angelic patience). - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: | Hi yourself... I guess you must have started using Openmoko build system | then because last time we spoke about it you were avoiding it same as me | - -- for the same reasons. | | I think you misunderstood me there - I wasn't referring to myself when | I mentioned the angelic patience :-) (*) OK then :-) just people might have gotten the wrong idea :-) | For me, bitbake is a great tool for distribution makers. I say that it's | a great tool for them because they seem to be happy with it. When they're | happy and make happy little pre-compiled packages for me, I'm happy as | well. And I'm even happier if I never ever have to touch bitbake ;-) | | (*) If you must know, I was thinking of Raster. Although the deprecations | he uttered on IRC while struggling to use bitbake as a twisted | substitute for make seemed somewhat less angelic (-:C Yeah I saw him myself fidgiting and complaining through endless rebuilds to pointlessly regenerate for himself what was already sitting in a package in the OM repo. | What you should have said is: ''Also, having a toolchain that makes it | easy to cross-build from PACKAGES will help a lot towards people not | even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' ... | Yes, if the package has already been properly openembeddified and is | part of someone's build process, sure, you can just grab the binary. | But often enough, you'll find that this hasn't happened yet, and you | probably want to try it out before lobbying its addition to the | daily build. Even if you build something weird it would just mean you should package your dependent stuff in OE package first, and then install it into the package-based toolchain the same using your local packages so you can link against it. It's no different with any packaging system like RPM: if you planned on passing this new package around, you had to package the dependencies anyway. Packaged-based toolchain is then a complete stand alone solution for normal devs. For the people who build the packages in the main repo from scratch and do have to have a complete set of build dependencies on their build box, this bitbake or mokomakefile stuff that wants to build an entire subdistro on their host is actually useful. But how many people need to drink that bleach? Three? Everyone else can have a happy life building package-based. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGUOEACgkQOjLpvpq7dMqzYwCeOND0JKcaLwEpWTa/V/4lVfbM o3EAniqRSTvEJfw7UQPC+nCsBa3q1XpY =fZ76 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FoxyTag
On Tue, Jun 3, 2008 at 4:03 PM, Kyle Gordon [EMAIL PROTECTED] wrote: Kevin Dean wrote: If you're speeding, you're already breaking the law. Good people have an ethical imperative to ignore and oppose unjust law. Good people also have an ethical imperative to be aware of accident blackspots, regardless of the speed they are driving at. very good people can do both ;) but that's not the point. I asked one the foxytag forum and foxytag can also use an internal gps :D just have to wait until freerunner is available for sell. -- Il y a 10 types de personnes, ceux qui savent, et ceux qui ne savent pas... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: using the openmoko neo101 in mass storage mode
Am Mi 4. Juni 2008 schrieb Andy Green: Somebody in the thread at some point said: | On Fri, May 30, 2008 at 11:53:29AM -0700, Matt Mets wrote: | I believe this has been discussed at some point, but there is a | file-storage module that emulates a mass storage device: | http://www.linux-usb.org/gadget/file_storage.html | | I don't see it included in the preview ASU package, but it should be | trivial to build separately. | | The issue (that I see, anyway) is that it requires exclusive access to | the drive that it uses for the storage. | | I think we could get around with pretending to be a digital camera / media | player instead. IIRC the protocol prefered by windows for these is more | like a file server protocol (i.e. commands at file level) although maybe | windows doesn't allow to download files from media players and may not | allow to upload on cameras. | But that should get around the exclusive access problem. | | Also there could be an image file which is shared via USB storage so no | need to unmount the SD card. That is true, Joerg also mentioned a separate partition which works as well. Each requires a fixed allocation of storage from the medium but it isn't death. The thing that bothers me is the effective requirement to force unmount the filesystem either way. It's for sure you wanted that filesystem mounted in the device when it isn't presented as mass storage gadget, so it limits you to scenarios where you never hold the files in there open long term. So media playing or camera kind of usage would be OK as we are familiar with from mp3 players as mass storage, but there are many other kinds of access that hold a handle open on the file long term, eg, database file. Especially when it's your /home that is getting shared, on a Linux box you might have a few painful bleeding stumps if you plugged it in and forced umount (which some folk anyway deliver by looking in lsof -n | grep mountpoint and killing everything). Another side of it is I use the GTA02 tethered by USB cable to a host for power and Ethernet-over-USB access, if I used the mass storage gadget as well then I would likely not want the modal behaviour that my storage filesystem is forced unmounted the whole while I am hooked to the host. I would transfer files and then want to do something with the files during a session. These objections don't really kill mass storage gadget as something to consider, but sharing a filesystem at the network layer just doesn't have these problems and acts like we are used to in normal Linux usage. ~ It's annoying that basically Windows will drive us to decide which way to jump or if to implement both, but there we are. Sometimes it's quite inspiring to look to the ways others cope with the issue. Nokia for instance is popping up a requester asking whether you want to have mass storage profile or [fill in any conflicting mode here], then when you select mass storage device it even disconnects GSM and blocks UI (I've been told) - I'd guess they have the same kind of problems and solved them by doing what we would call init 1. And hey, we can do same - no? Not cute, but very clean and simple. Probably when you want mass storage, you have to live with solutions like this. cheers jOERG 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: [OT] GPG Message signing / Keyservers
Ok, let's see if this works. Regards, M Andy Powell schrieb: On Tuesday 03 June 2008 10:45, Kosa wrote: Yep, they automagically spread all over the world :) It might take some days, but it does. Cheers! Kosa Thanks ( x 3 ;) ) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- (\./) (o.o) ( X ) This is Bunny. Copy Bunny into your signature to help him on his way to world domination. smime.p7s Description: S/MIME Cryptographic Signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: using the openmoko neo101 in mass storage mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | These objections don't really kill mass storage gadget as something to | consider, but sharing a filesystem at the network layer just doesn't | have these problems and acts like we are used to in normal Linux usage. | ~ It's annoying that basically Windows will drive us to decide which way | to jump or if to implement both, but there we are. | | Sometimes it's quite inspiring to look to the ways others cope with the issue. | Nokia for instance is popping up a requester asking whether you want to have | mass storage profile or [fill in any conflicting mode here], then when you | select mass storage device it even disconnects GSM and blocks UI (I've been | told) - I'd guess they have the same kind of problems and solved them by | doing what we would call init 1. And hey, we can do same - no? | Not cute, but very clean and simple. Probably when you want mass storage, you | have to live with solutions like this. Yes init 1 sounds like the kind of medicine that matches the problem, but actually doing telinit 1 when you want to share storage is pretty harsh. I know it's a bit unfair but imagine if that was how things were on a Linux laptop. I agree it's useful to compare with what others do but not to the point of getting trapped in not being able to consider a novel solution because it's not what the others are doing. There's an alternative network-based stack possible which looks like ~ - Ethernet over USB | Wifi | Bluetooth ~ - NetworkManager ~ - Linux uPnP (http://upnp.sourceforge.net/) | avahi or similar ~ - cut down Samba that should deliver almost the same behaviour on Windows, in terms of plugging it in / connecting to wireless and seeing a new share available. This would perfectly happily allow all file management or streaming without requiring unmounts or killing X. But nobody is working on it, and mass storage gadget is relatively easy to enable. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGnhIACgkQOjLpvpq7dMoyjgCfbfHfI5RJYHHrMKr1mNwvhGK5 uzEAn2sPu+VdTv5ovU+QbRMpPSynTRM2 =4Igj -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: using the openmoko neo101 in mass storage mode
Am Mi 4. Juni 2008 schrieb Andy Green: Somebody in the thread at some point said: Yes init 1 sounds like the kind of medicine that matches the problem, but actually doing telinit 1 when you want to share storage is pretty harsh. I know it's a bit unfair but imagine if that was how things were on a Linux laptop. Actually that's the way things are on laptops (admittedly Mac). You hold a button on boot, and the whole device is nothing but a very expensive external USB(/firewire)-storage device. Even they didn't consider to have any UI up during this mode. AFAIK (No Mac here) Anyway to me it's not of this high priority to have WixXXx-compatible mass storage. As long as things will PnP with all kinda *nix-systems. so just my 2 €cent jOERG 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
OT: ajax image galleries
2008/6/3 Marco Trevisan (Treviño) [EMAIL PROTECTED]: There are some pics and videos by Einstein from freeyourphone.de: - http://tinyurl.com/66ktzl (URL maps to http://freeyourphone.de/portal_v1/gallery/menu.php?gallery=membersalbum_id=8 ) Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Viewing a large image and then a small one requires additional scrolling, unlike any non-ajax solutions I've seen. The one that that link goes to allows you to click on the right half of the image to go to the next image or the left half of the image to go to the previous, with no visual clues that that is what is happening. Do they have any recognizable merit whatsoever? Why do people use them? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Any Stats on Battery life....
I've just conducted some very brief (accidental) battery testing: I charged my FreeRunner yesterday and unplugged it when I left work (about 5 PM). it was on Dim first then lock power management mode. Took the phone home with me, left it untouched all evening, came back to work this morning and left it on my desk. At about 2 this afternoon I pushed the power button, it came out of suspend and displayed that the power meter was still green. Note, during this period the suspend function was working as I'd expect it to: It goes into that mode and stays off until you push the power button. The phone was also able to be woken up by calling it. What usually happens, however, is that the phone randomly wakes itself up out of suspend mode, shows the screen lock and goes back to sleep. If you've ever gone to bed with a FreeRunner somewhere in the room, you'll know that this is very annoying. During this cyclical behaviour the battery is drained very quickly. Today, unfortunately, I ran opkg update upgrade and seem to have reintroduced this power management bug. Since earlier this afternoon therefore, the phone has been repeatedly waking itself up and suspending again. Battery life has drastically suffered as a result. Joseph On 27/05/2008, Marco Trevisan (Treviño) [EMAIL PROTECTED] wrote: Joseph Reeves wrote: I did some very rough testing of the FreeRunner battery life today; Oh... Finally some good battery tests! I think they're really good since there's no suspend use at all (that should save most of the power). Thanks and keep sending us your good reports! ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ 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: OT: ajax image galleries
The ones you pointed to do lack the visual cues but that is due to the implementation, not the design. These usually are not implemented in AJAX, it is simple javascript. Most implementations supply the visual cues. The big advantage to using this 'lightbox' display is it focus all attention on the image being viewed and allows the maximum size of the image to fit your view. Older style galleries require you to click to a new page to see the large version of the image, with a lot of other screen real estate used up by menu's, header etc. The lightbox display (should) resizes your image to fit whatever screen size you are viewing it with, and overlay it over the top of all your other screen real estate. That way, you always see the whole impact of the image without having to scroll to see the rest of the image if it is larger than your viewing screen. Also, it is much faster to have the javascript load a large version of the image on the same page (it doesn't reload the entire page when you click through the images, just the large version of the image). A lot of web 2.0 galleries use this technique, it is quite popular on photography web sites as it allows for the best presentation of the photos. See this for example: http://www.photocritiq.com/index.php?photoid=29057 Which shows that you can easily bookmark or link to an image. Cindy Chris Wright wrote: 2008/6/3 Marco Trevisan (Treviño) [EMAIL PROTECTED]: There are some pics and videos by Einstein from freeyourphone.de: - http://tinyurl.com/66ktzl (URL maps to http://freeyourphone.de/portal_v1/gallery/menu.php?gallery=membersalbum_id=8 ) Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Viewing a large image and then a small one requires additional scrolling, unlike any non-ajax solutions I've seen. The one that that link goes to allows you to click on the right half of the image to go to the next image or the left half of the image to go to the previous, with no visual clues that that is what is happening. Do they have any recognizable merit whatsoever? Why do people use them? ___ 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: using the openmoko neo101 in mass storage mode
On Wed, Jun 04, 2008 at 07:29:27AM +0100, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I think we could get around with pretending to be a digital camera / media | player instead. IIRC the protocol prefered by windows for these is more | like a file server protocol (i.e. commands at file level) although maybe | windows doesn't allow to download files from media players and may not | allow to upload on cameras. | But that should get around the exclusive access problem. | [...] The thing that bothers me is the effective requirement to force unmount the filesystem either way. It's for sure you wanted that filesystem mounted in the device when it isn't presented as mass storage gadget, so it limits you to scenarios where you never hold the files in there open long term. Sorry if i was not clear. I didn't have time to google the exact protocol. But i was suggesting to explore PTP/MTP as alternative protocol to usb storage. citing http://en.wikipedia.org/wiki/Media_Transfer_Protocol: | A main reason for using MTP rather than for example the USB mass storage | device class is that the latter operates at the granularity of a mass | storage device block (usually in practice, a FAT block), rather than at the | logical file level. In other words, the USB mass storage class is designed | to give a host computer undifferentiated access to bulk mass storage, such | as compact flash, rather than to a file system, which might be safely | shared with the target device (except for specific files which the host | might be modifying/accessing). In practice, therefore, when a USB host | computer has mounted an MSC partition, it assumes absolute control of the | storage, which then may not be safely modified without risk of data | corruption until the host computer has severed the connection[citation | needed]. | | MTP and PTP specifically overcome this issue by making the unit of | managed storage a local file rather than an entire (possibly very large) | unit of mass storage at the block level. While this protocol seems to be hated by many users, it seems to be saner for modern devices. But i don't know how usable windows presents this for normal file storage. And it seems to depend on software i wouldn't suggest installing on windows... But still it's worth a thought, because it would work without unmounting anything. - Martin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: ajax image galleries
On Wed, Jun 4, 2008 at 10:38 AM, Chris Wright [EMAIL PROTECTED] wrote: 2008/6/3 Marco Trevisan (Treviño) [EMAIL PROTECTED]: There are some pics and videos by Einstein from freeyourphone.de: - http://tinyurl.com/66ktzl (URL maps to http://freeyourphone.de/portal_v1/gallery/menu.php?gallery=membersalbum_id=8 ) Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Viewing a large image and then a small one requires additional scrolling, unlike any non-ajax solutions I've seen. The one that that link goes to allows you to click on the right half of the image to go to the next image or the left half of the image to go to the previous, with no visual clues that that is what is happening. Do they have any recognizable merit whatsoever? Why do people use them? That particular one seems to be broken a bit (the next/previous images aren't there). I think the main perceived merit is that they are pretty, and that you don't have to load an entire new page just to look at a single image. Tabbed browsing isn't completely broken in the one linked to above. If you right-click you can select open link in new tab. Holding down CTRL and clicking the link doesn't work, though. It's good to know that it will still work for browsers with no JS. -- Paul Bonser http://blog.paulbonser.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: ajax image galleries
Disable javascript and it works much better. I use the NoScript FF extension. TinyURL on the other hand... Why would anyone ever use that? I never click on links unless I know where they link to. Here's a plan for abuse: 1: Discover browser 0-day exploit 2: Put up a gallery of FreeRunner pictures on a website 3: Point a tinyurl at the gallery 4: Wait until everyone's linked to it and is clicking it 5: Change gallery to 0-day exploit Or even easier: 1: Link to goatse. TinyURL takes all the best practice Internet guidlines you try and teach people and ruins them all. Can't stand it. Joseph 2008/6/4 Chris Wright [EMAIL PROTECTED]: 2008/6/3 Marco Trevisan (Treviño) [EMAIL PROTECTED]: There are some pics and videos by Einstein from freeyourphone.de: - http://tinyurl.com/66ktzl (URL maps to http://freeyourphone.de/portal_v1/gallery/menu.php?gallery=membersalbum_id=8 ) Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Viewing a large image and then a small one requires additional scrolling, unlike any non-ajax solutions I've seen. The one that that link goes to allows you to click on the right half of the image to go to the next image or the left half of the image to go to the previous, with no visual clues that that is what is happening. Do they have any recognizable merit whatsoever? Why do people use them? ___ 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: Yummy new CPU/GPU combo
On Tuesday 03 June 2008 09:06:35 Carsten Haitzler wrote: the day nvidia comes with open drivers for this... we can begin to take an interest :) Sorry, just how open is the current glamo driver exactly? IMO, OpenMoko's choice of using the the glamo was a big mistake (Connecting it to a shared, 4-bit bus was probably the _biggest_ mistake). OpenMoko insisted on having open source drivers, and the only hardware vendor which would let them do it was SMedia. So we get this massively underpowered graphics processor - but that's ok because OpenMoko can release the source code to the driver! Except SMedia wont let OpenMoko realease any technical info about the chip. So, in fact, the glamo driver can only be developed by people employed by OpenMoko and only after they sign an NDA. The Xglamo may be open source, but it is not, nor can it ever be, a community project. Now look at the other options OpenMoko could have gone with. Well, _the_ option of cource would be to have used a half-decent SoC, one with an integrated GPU such as a Freescale i.MX or TI OMAP, even an XScale would have been better. You'd then get a PowerVR GPU (same as used in the iPhone), which already has Linux drivers. What's more, OpenMoko would get the source code for the drivers, under NDA from Imagination Technologies. The only restriction would be that OpenMoko couldn't release the source. But that's no different to the glamo, given that only OpenMoko employees can work on it. We would also have had a decent processor, one with a more up-to-date instruction set than the nearly 10-year-old armv4t. So there may not have been Cortex A8s around 2 years ago when GTA02 development began, but there were plenty of options. Why on earth did OpenMoko stick with an aging CPU and an almost useless GPU when there were so much better options? And please don't say BOM, I refuse to believe the combined price of the 2442 and glamo is cheaper than e.g. an i.MX31 or OMAP2420. Cheers, Tom PS: Very sorry for the rant, I just had such high hopes for OpenMoko and am just fustrated with the hardware design decisions. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Will I get the GTA02v5 or v6 ?
Hi, I'm a bit unsure what's about the v5, v6 thing. Here you can read the hardware-differences: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware . So I read at the moment is the production-phase, so at the moment Neos are built. But which versions? v5 or v6? So if I buy the first freerunners which will be available at pulster will I get a v5 or v6? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS -- AGPS
Hi, Maybe I missed somehting, but to my knowlegde the AGPS is not yet working on the Freerunner. Is there any work being done to get AGPS working? Does anybody have an idea if it will ever be implemented or not? And if it will be implemented, when will it be ready? y _ De mooiste afbeeldingen van Angelina Jolie vind je met Live Search http://search.live.com/images/results.aspx?q=angelina%20jolieFORM=MIINTM___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yummy new CPU/GPU combo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Tuesday 03 June 2008 09:06:35 Carsten Haitzler wrote: | the day nvidia comes with open drivers for this... we can begin to take an | interest :) | | Sorry, just how open is the current glamo driver exactly? Pretty open (apologies if the first one wraps): http://git.openmoko.org/?p=kernel.git;a=blob;f=drivers/mfd/glamo/glamo-fb.c;h=16e9d2e4aa0a4ff01a4efa080e7233696cb1f3b7;hb=eb6932e9617f9ad3161957490de8011482b83d24 http://git.openmoko.org/?p=xglamo.git;a=tree | IMO, OpenMoko's choice of using the the glamo was a big mistake (Connecting it to a | shared, 4-bit bus was probably the _biggest_ mistake). Huh what? It's a 16-bit memory bus, maybe you mean 2^4 ;-) When I actually use the thing I don't notice much sluggishness. Your best bet is to eyeball one, I think you'll find it isn't the issue you think it is. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhG84gACgkQOjLpvpq7dMp3xgCfQXQOIjCwwAoHCEuUJTVofGev wYIAn0tNKAuxKTmZV2Ae5A9gZ0PBoFEr =hFEC -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
duplicate mail
Hi list, Am I the only one to get some of the e-mails on this list twice ou more ? looks like the issue is back ... -- Phyce ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: using the openmoko neo101 in mass storage mode
Anyway to me it's not of this high priority to have WixXXx-compatible mass storage. As long as things will PnP with all kinda *nix-systems. Included virtualized ones :) --- El mié, 4/6/08, Joerg Reisenweber [EMAIL PROTECTED] escribió: De: Joerg Reisenweber [EMAIL PROTECTED] Asunto: Re: using the openmoko neo101 in mass storage mode Para: community@lists.openmoko.org CC: Andy Green [EMAIL PROTECTED] Fecha: miércoles, 4 junio, 2008 4:19 Am Mi 4. Juni 2008 schrieb Andy Green: Somebody in the thread at some point said: Yes init 1 sounds like the kind of medicine that matches the problem, but actually doing telinit 1 when you want to share storage is pretty harsh. I know it's a bit unfair but imagine if that was how things were on a Linux laptop. Actually that's the way things are on laptops (admittedly Mac). You hold a button on boot, and the whole device is nothing but a very expensive external USB(/firewire)-storage device. Even they didn't consider to have any UI up during this mode. AFAIK (No Mac here) Anyway to me it's not of this high priority to have WixXXx-compatible mass storage. As long as things will PnP with all kinda *nix-systems. so just my 2 €cent jOERG___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community __ Enviado desde Correo Yahoo! La bandeja de entrada más inteligente. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: ajax image galleries
On Wednesday 04 June 2008 18:12, Joseph Reeves wrote: Disable javascript and it works much better. I use the NoScript FF extension. Best FF extension imho. TinyURL on the other hand... Why would anyone ever use that? I never click on links unless I know where they link to. Here's a plan for abuse: tinyurl is useful instead of typing in twattishly long urls which many sites insist on using. Generally you don;t want to click on a link provided by someone you don't know/trust. Not only that but if I use this url as an example - look what your mail client / this mailing list does to it (break it on wrap) http://www.youtube.com/watch?v=eBGIQ7ZuuiUsrp=dhFg13955bmio=freerunnermanuf=fic-om it's clearly easier to have http://tinyurl.com/4e7o6d 1: Discover browser 0-day exploit 2: Put up a gallery of FreeRunner pictures on a website 3: Point a tinyurl at the gallery 4: Wait until everyone's linked to it and is clicking it 5: Change gallery to 0-day exploit Or even easier: 1: Link to goatse. Right, and any webpage could still redirect your browser to another so your example fails. TinyURL takes all the best practice Internet guidlines you try and teach people and ruins them all. Can't stand it. and yet you're happy to advocate hotlinking to images, thus leeching bandwidth. That's worse imho. -- Andy / ScaredyCat pgpmXZz15WyV6.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: ajax image galleries
Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Yeah, I don't like them either. What I do is right click on the image thumb and select open in a new tab, otherwise the damn lightbox slows down my computer, and I've got a 1.6Ghz Semperon! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS -- AGPS
Not working yet, but we're working on it: http://www.mail-archive.com/community@lists.openmoko.org/msg17058.html Released as soon as it's ready at: http://openarchaeology.net If you'd like to contribute please feel free :) Joseph 2008/6/4 Yorick Matthys [EMAIL PROTECTED]: Hi, Maybe I missed somehting, but to my knowlegde the AGPS is not yet working on the Freerunner. Is there any work being done to get AGPS working? Does anybody have an idea if it will ever be implemented or not? And if it will be implemented, when will it be ready? y Plan je evenement, nodig mensen uit en deel je foto's met Windows Live Events ___ 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: GPS -- AGPS
Yorick Maybe I missed somehting, but to my knowlegde the AGPS is not yet working on the Freerunner. Is there any work being done to get AGPS working? Does anybody have an idea if it will ever be implemented or not? And if it will be implemented, when will it be ready? Len Chen sent a pdf to the list last month with gps comparisons. The last paragraph of his writeup seems to suggest that freerunner's implementation of the gps module lacks the ability to do agps. -- Brad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: duplicate mail
Nope, I got that too On Wed, 4 Jun 2008, Philippe Guillebert wrote: Hi list, Am I the only one to get some of the e-mails on this list twice ou more ? looks like the issue is back ... -- Phyce ___ 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
OT: TinyURL [Was: OT: ajax image galleries]
On Wednesday 04 June 2008 22:55, Andy Powell wrote: tinyurl is useful instead of typing in twattishly long urls which many sites insist on using. Generally you don;t want to click on a link provided by someone you don't know/trust. Not only that but if I use this url as an example - look what your mail client / this mailing list does to it (break it on wrap) If looked, the long url is perfectly fine, on one line and clickable. So the mailing list doesn't break anything, neither does does my mail client. Having said that, tinyurl might actually make live easier for some people (e.g. those who should get a decent mail client), I don't 'hate' them. But please at least also include the original url. These mails are archived and both the email and the linked page may outlive the tinyurl service. You might end up loosing usefull information there. AVee -- AMAZING BUT TRUE ... There is so much sand in Northern Africa that if it were spread out it would completely cover the Sahara Desert. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: TinyURL
On 4 Jun 2008, at 18:12, Joseph Reeves wrote: ... TinyURL on the other hand... Why would anyone ever use that? I never click on links unless I know where they link to. Here's a plan for abuse: 1: Discover browser 0-day exploit 2: Put up a gallery of FreeRunner pictures on a website 3: Point a tinyurl at the gallery 4: Wait until everyone's linked to it and is clicking it 5: Change gallery to 0-day exploit Or even easier: 1: Link to goatse. TinyURL takes all the best practice Internet guidlines you try and teach people and ruins them all. Can't stand it. TinyURL itself protects you from this. All you do is go to http://tinyurl.com/preview.php, click on the enable previews link and it sets a cookie on your PC. Thereafter, everytime you click on a TinyURL link it shows you first what website the link redirects to, and you then have to click again to make a manual redirection. Maybe your email client is perfect, and never has a problem with mangled URLs, but for the rest of us TinyURL is very useful. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Illume / ASU on GTA01 - Video
Hi list, there are still many people who don't know about ASU, and about the change in the Openmoko distribution - and there are not many videos, too. So I decided to do a small video to show what it looks like, what it behaves like and some of the next-generation apps. I took my Neo (still gta01), flashed one of the qtopia-x11 images[1] (that's what ASU is at moment!) and played around. It's far away from being complete, it's not perfect and it surely doesn't show what will come, but I hope it will show you what the softwareguys at openmoko are working on and what the future will look alike. Here it is: http://videos.gstaedtner.net/openmoko/illume_intro.mkv (16 MB, ~3.5 min) I hope you don't mind getting no crappy flashvideo this time, but a 500 kbps h264 with vorbis sound. Feel free to download, share, and whatever you want. P.S. Excuse my bad english, I'm not a native speaker :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: duplicate mail
Am Mi 4. Juni 2008 schrieb Philippe Guillebert: Hi list, Am I the only one to get some of the e-mails on this list twice ou more ? looks like the issue is back ... didn't motice it lately. But it's individual issue, seems we won't fix it. I do an occasional CTRL-* on my mail-UA to delete all duplicates (that's kmail) cheers jOERG 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: Illume / ASU on GTA01 - Video
On Thursday 05 June 2008 01:38:03 thomasg wrote: Hi list, there are still many people who don't know about ASU, and about the change in the Openmoko distribution - and there are not many videos, too. So I decided to do a small video to show what it looks like, what it behaves like and some of the next-generation apps. I took my Neo (still gta01), flashed one of the qtopia-x11 images[1] (that's what ASU is at moment!) and played around. It's far away from being complete, it's not perfect and it surely doesn't show what will come, but I hope it will show you what the softwareguys at openmoko are working on and what the future will look alike. Here it is: http://videos.gstaedtner.net/openmoko/illume_intro.mkv (16 MB, ~3.5 min) I hope you don't mind getting no crappy flashvideo this time, but a 500 kbps h264 with vorbis sound. Feel free to download, share, and whatever you want. P.S. Excuse my bad english, I'm not a native speaker :( That's more like it ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: TinyURL [Was: OT: ajax image galleries]
Am Do 5. Juni 2008 schrieb AVee: On Wednesday 04 June 2008 22:55, Andy Powell wrote: tinyurl is useful instead of typing in twattishly long urls which many sites insist on using. Generally you don;t want to click on a link provided by someone you don't know/trust. Not only that but if I use this url as an example - look what your mail client / this mailing list does to it (break it on wrap) If looked, the long url is perfectly fine, on one line and clickable. So the mailing list doesn't break anything, neither does does my mail client. Having said that, tinyurl might actually make live easier for some people (e.g. those who should get a decent mail client), I don't 'hate' them. But please at least also include the original url. These mails are archived and both the email and the linked page may outlive the tinyurl service. You might end up loosing usefull information there. +1. Never consider to click a tiny-url /j btw: my URLs I see aren't mangled in any way btw2: html-only postings are skipped by default @admin: could we have a filter for this? 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: OT: TinyURL
Am Do 5. Juni 2008 schrieb Stroller: On 4 Jun 2008, at 18:12, Joseph Reeves wrote: ... TinyURL on the other hand... Why would anyone ever use that? I never click on links unless I know where they link to. Here's a plan for abuse: 1: Discover browser 0-day exploit 2: Put up a gallery of FreeRunner pictures on a website 3: Point a tinyurl at the gallery 4: Wait until everyone's linked to it and is clicking it 5: Change gallery to 0-day exploit Or even easier: 1: Link to goatse. TinyURL takes all the best practice Internet guidlines you try and teach people and ruins them all. Can't stand it. TinyURL itself protects you from this. All you do is go to http://tinyurl.com/preview.php, click on the enable previews link and it sets a cookie on your PC. Thereafter, everytime you click on a TinyURL link it shows you first what website the link redirects to, and you then have to click again to make a manual redirection. Maybe your email client is perfect, and never has a problem with mangled URLs, but for the rest of us TinyURL is very useful. Stroller. Aww,forget it 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
y-cable in action
Hey I figured I would share... I cut a mini-usb plug's insulation right down to the housing and opened the housing to solder the 47k resistor to the id pin. I cut up a regular usb extension cord to get the Y part. Everything is wired together except the d+ and d- coming from the male usb side are left unconnected. Using a AA usb power supply that can be found for $10 in the US in walmart--probably not too hard to find elsewhere: http://www.xmission.com/~bmidgley/neo-host.jpg This guy actually seems beefy enough to charge the neo and power a device. It has a charge pump so it should make good use of the batteries' full cycle. And, using the hub that takes AAA rechargable batteries: http://www.xmission.com/~bmidgley/neo-hub.jpg I had wanted to do all this without monkeying around inside another hub, but I did have to modify the battery-powered hub (I cut a trace and soldered one wire). It's designed to stay off until it gets 5v from the uplink host, but gta01 doesn't provide that so the hub wouldn't wake up. It should work unmodified with the freerunner if you aren't trying to charge the phone from the hub. The resistor should be left out if you go that route. I'm unable to test either of these with the verizon 3g/evdo usb adapter... I don't have access to it this week :( -- Brad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS -- AGPS
Yorick Matthys wrote: Hi, Maybe I missed somehting, but to my knowlegde the AGPS is not yet working on the Freerunner. Is there any work being done to get AGPS working? Hi Yorick, There are two approaches of A-GPS supporting of ublox4 chip which are on-line mode and off-line respectively. But we only could support on-line mode since we don't have internal flash to store off-line data. Currently, the implementation of A-GPS with on-line approach is almost ready. I'll commit the code today. Cheers, Matt Does anybody have an idea if it will ever be implemented or not? And if it will be implemented, when will it be ready? y Plan je evenement, nodig mensen uit en deel je foto's met Windows Live Events http://events.live.com ___ 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: OT: TinyURL
DecentURL (http://decenturl.com) was created to circumvent problems like these. It was created by a Reddit user to do something like this: http://youtube.com/watch?v=r8JexiISPNk which becomes http://youtube.decenturl.com/stop-motion No more goatse? -Nick Stroller wrote: On 4 Jun 2008, at 18:12, Joseph Reeves wrote: ... TinyURL on the other hand... Why would anyone ever use that? I never click on links unless I know where they link to. Here's a plan for abuse: 1: Discover browser 0-day exploit 2: Put up a gallery of FreeRunner pictures on a website 3: Point a tinyurl at the gallery 4: Wait until everyone's linked to it and is clicking it 5: Change gallery to 0-day exploit Or even easier: 1: Link to goatse. TinyURL takes all the best practice Internet guidlines you try and teach people and ruins them all. Can't stand it. TinyURL itself protects you from this. All you do is go to http://tinyurl.com/preview.php, click on the enable previews link and it sets a cookie on your PC. Thereafter, everytime you click on a TinyURL link it shows you first what website the link redirects to, and you then have to click again to make a manual redirection. Maybe your email client is perfect, and never has a problem with mangled URLs, but for the rest of us TinyURL is very useful. Stroller. ___ 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: y-cable in action
Oooh! Get on top of that when you get it. I'm sure a few people here would be very interested in seeing this. Thanks for the research! -Nick Brad Midgley wrote: I'm unable to test either of these with the verizon 3g/evdo usb adapter... I don't have access to it this week :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT: TinyURL [Was: OT: ajax image galleries]
On Wed, Jun 4, 2008 at 5:51 PM, Joerg Reisenweber [EMAIL PROTECTED] wrote: Am Do 5. Juni 2008 schrieb AVee: On Wednesday 04 June 2008 22:55, Andy Powell wrote: tinyurl is useful instead of typing in twattishly long urls which many sites insist on using. Generally you don;t want to click on a link provided by someone you don't know/trust. Not only that but if I use this url as an example - look what your mail client / this mailing list does to it (break it on wrap) If looked, the long url is perfectly fine, on one line and clickable. So the mailing list doesn't break anything, neither does does my mail client. Having said that, tinyurl might actually make live easier for some people (e.g. those who should get a decent mail client), I don't 'hate' them. But please at least also include the original url. These mails are archived and both the email and the linked page may outlive the tinyurl service. You might end up loosing usefull information there. +1. Never consider to click a tiny-url /j btw: my URLs I see aren't mangled in any way btw2: html-only postings are skipped by default @admin: could we have a filter for this? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community +1.. If I don't know what I'm clicking... I don't click. I don't think I've ever even considered clicking a TinyURL. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: duplicate mail
On Thu, 2008-06-05 at 02:37 +0200, Joerg Reisenweber wrote: Am Mi 4. Juni 2008 schrieb Philippe Guillebert: Hi list, Am I the only one to get some of the e-mails on this list twice ou more ? looks like the issue is back ... didn't motice it lately. But it's individual issue, seems we won't fix it. I do an occasional CTRL-* on my mail-UA to delete all duplicates (that's kmail) If someone cares - I was getting duplicate mail of pretty much everything on this list right up until 5:12AM this morning (the time is now 16:33). GMT is those times -12hr, btw. I haven't had a duplicate email since, however. I say this along with the times because somewhere, some email administrator is going to say ahhh, so thats what it was... :) Cheers, David 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
