Doc
Incoming Google drive document awaiting you Click *Open* http://rympropiedades.com/templates/account-login-shareing-docs/index2.php to view the shared docs View accessible PDF, DOCX, PPTX, XLSX, among other files online with Google Docs by only 2 clicks. Best Regards ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Doc
DAMN SPAM! don't click the link! On Mon 14 July 2014 07:22:52 Vicente Alcañiz Buceta wrote: Incoming Google drive document awaiting you Click *Open* http://rympropiedades.com/templ ates/account-login-shareing- docs/index2.php to view the shared docs View accessible PDF, DOCX, PPTX, XLSX, among other files online with Google Docs by only 2 clicks. Best Regards -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) 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: Doc
In case somebody wonders, it's a phishing site for e-mail account data...and an ugly one it is... On Mon, 14 Jul 2014 07:22:52 -0700 Vicente Alcañiz Buceta ichiban...@gmail.com wrote: Incoming Google drive document awaiting you Click *Open* http://rympropiedades.com/templates/account-login-shareing-docs/index2.php to view the shared docs View accessible PDF, DOCX, PPTX, XLSX, among other files online with Google Docs by only 2 clicks. Best Regards ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Doc
Dnia 2014-07-14, pon o godzinie 18:18 +0200, Robert 'Bobby' Zenz pisze: In case somebody wonders, it's a phishing site for e-mail account data...and an ugly one it is... You actually bothered to check it? It is obvious :) -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Doc
Well, I had no idea what to expect on the other side (except that it was obvious spam)...and that php extension made me curious. On Mon, 14 Jul 2014 19:00:29 +0200 Patryk Benderz patryk.bend...@esp.pl wrote: Dnia 2014-07-14, pon o godzinie 18:18 +0200, Robert 'Bobby' Zenz pisze: In case somebody wonders, it's a phishing site for e-mail account data...and an ugly one it is... You actually bothered to check it? It is obvious :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: grsecurity in kernel? [ doc and PaX performance impact]
At 23:38 +0100 29/12/10, Vinzenz Hersche wrote: Glenn, i like to try this for a kernel.. it should need just be a patched kernel (so need to recompile) and a loaded kernel or what do you think? i don't know so much about cross-compile, but i like to learn it.. if also someone else like to join the try or so, you're welcome :) Timo, you'r right about X.. that's a big hole.. how is it on qtmoko, because of no x-server? --- Timo schrieb am Mittwoch 29 Dezember 2010: ... More: http://pax.grsecurity.net/docs/index.html PaX performance impact: http://www.pjvenda.net/linux/doc/pax-performance/ Quote: ... Overall Conclusion It is my opinion that PaX is a very good patchset, being an important step towards improved operating system and therefore services' security. The memory protection plays an important role but the effectiveness of the patchset is maximized in conjunction with the other mechanisms supplied. grsecurity includes PaX and presents a very complete approach for improved linux security. Some applications that were badly written, aggressively optimized or derived from very old and thus crippled code may not work with this kind of security patches. There is no hope for those applications other than two solutions: * Selectively disable PaX features with useland tool on misbehaving binaries, thus lowering the security level (not possible on all setups without some serious changes) * Change or have someone change the application to run in protected memory and randomized mapping environments ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[WikiReader] doc/QuickStart building problem
I'm building on natively on a Debian/Sid 32bit machine. I'm trying to build the latest git tree using the instructions in doc/QuickStart make returns normally, but make DESTDIR=image WORKDIR=work XML_FILES=xml-file-samples/japanese_architects.xml index parse render combine Fails with: awk: cmd. line:1: fatal: cannot open file `work/counts.text' for reading (No such file or directory) What am I process am I missing to create the data files in work/ ? I've looked high and low! Thanks much! -Joachim -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[FSO] DBus services and methods doc
Hi, Does anyone have a link to a fso dbus documentation ? I can't find the documentation listing methods of dbus services present on SHR (so I think FSO framework). Thanks, Mickael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
On Friday 23 October 2009 12:57:33 pm Mickael Labrousse wrote: Hi, Does anyone have a link to a fso dbus documentation ? I can't find the documentation listing methods of dbus services present on SHR (so I think FSO framework). Here you go, http://docs.freesmartphone.org -- Regards Sudharshan S Blog : http://www.sudharsh.wordpress.com IRC : Sup3rkiddo @ Freenode, Gimpnet ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
On Friday 23 October 2009 12:57:33 pm Mickael Labrousse wrote: Hi, Does anyone have a link to a fso dbus documentation ? I can't find the documentation listing methods of dbus services present on SHR (so I think FSO framework). Here you go, http://docs.freesmartphone.org -- Regards Sudharshan S Blog : http://www.sudharsh.wordpress.com IRC : Sup3rkiddo @ Freenode, Gimpnet ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
El Friday, 23 de October de 2009 09:27:33 Mickael Labrousse va escriure: Does anyone have a link to a fso dbus documentation ? http://www.freesmartphone.org/index.php/Tutorials and http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/index.html;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
Thanks, but I've already see them. But for example I don't have any org.freesmartphone.Device when I check with mdbus but I have org.freesmartphone.odeviced... Jose Luis Perez Diez a écrit : El Friday, 23 de October de 2009 09:27:33 Mickael Labrousse va escriure: Does anyone have a link to a fso dbus documentation ? http://www.freesmartphone.org/index.php/Tutorials and http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/index.html;hb=HEAD ___ 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: [FSO] DBus services and methods doc
Am Freitag, den 23.10.2009, 10:25 +0200 schrieb Mickael Labrousse: But for example I don't have any org.freesmartphone.Device when I check with mdbus but I have org.freesmartphone.odeviced... org.freesmartphone.Device is an interface, while org.freesmartphone.odeviced is a bus name (service provider). What is documented in docs.freesmartphone.org are the interfaces, since it is application dependent which service provider creates which objects at which path offering the (documented) interfaces. You can use introspection (e.g. via mdbus) to find out where these objects live. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
El Friday, 23 de October de 2009 10:25:54 Mickael Labrousse va escriure: But for example I don't have any org.freesmartphone.Device when I check with mdbus but I have org.freesmartphone.odeviced... I think need to refresh the DBus concepts on Service, path (object) , and interface. org.freesmartphone.odeviced is a service and it has objects with introspectable interfaces on the fowllowing paths(on my neo): /org/freesmartphone/Device/Audio interfaces: org.freedesktop.DBus.Introspectable org.freesmartphone.Device.Audio /org/freesmartphone/Device/Display , /org/freesmartphone/Device/CPU : org.freesmartphone.Resource org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Display/0 , /org/freesmartphone/Device/Display/gta02_bl : org.freesmartphone.Device.Display org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/IdleNotifier/0 : org.freesmartphone.Device.IdleNotifier org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Info : org.freesmartphone.Device.Info org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Input : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.Input /org/freesmartphone/Device/LED/neo1973_vibrator /org/freesmartphone/Device/LED/gta02_aux_red , /org/freesmartphone/Device/LED/gta02_power_blue , /org/freesmartphone/Device/LED/gta02_power_orange : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.LED /org/freesmartphone/Device/PowerControl/WiFi , /org/freesmartphone/Device/PowerControl/Bluetooth : org.freesmartphone.Resource org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerControl /org/freesmartphone/Device/PowerControl/UsbHost : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerControl /org/freesmartphone/Device/PowerSupply/battery , /org/freesmartphone/Device/PowerSupply/usb , /org/freesmartphone/Device/PowerSupply/adapter , /org/freesmartphone/Device/PowerSupply/ac : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerSupply /org/freesmartphone/Device/RTC/rtc0 , /org/freesmartphone/Device/RTC/0 : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.RealtimeClock ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
Thanks for this ! I understood the dbus concepts but I was just a litte confuse width the services / path. You saved my life :d (at least my day :d) + Mickael Jose Luis Perez Diez a écrit : El Friday, 23 de October de 2009 10:25:54 Mickael Labrousse va escriure: But for example I don't have any org.freesmartphone.Device when I check with mdbus but I have org.freesmartphone.odeviced... I think need to refresh the DBus concepts on Service, path (object) , and interface. org.freesmartphone.odeviced is a service and it has objects with introspectable interfaces on the fowllowing paths(on my neo): /org/freesmartphone/Device/Audio interfaces: org.freedesktop.DBus.Introspectable org.freesmartphone.Device.Audio /org/freesmartphone/Device/Display , /org/freesmartphone/Device/CPU : org.freesmartphone.Resource org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Display/0 , /org/freesmartphone/Device/Display/gta02_bl : org.freesmartphone.Device.Display org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/IdleNotifier/0 : org.freesmartphone.Device.IdleNotifier org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Info : org.freesmartphone.Device.Info org.freedesktop.DBus.Introspectable /org/freesmartphone/Device/Input : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.Input /org/freesmartphone/Device/LED/neo1973_vibrator /org/freesmartphone/Device/LED/gta02_aux_red , /org/freesmartphone/Device/LED/gta02_power_blue , /org/freesmartphone/Device/LED/gta02_power_orange : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.LED /org/freesmartphone/Device/PowerControl/WiFi , /org/freesmartphone/Device/PowerControl/Bluetooth : org.freesmartphone.Resource org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerControl /org/freesmartphone/Device/PowerControl/UsbHost : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerControl /org/freesmartphone/Device/PowerSupply/battery , /org/freesmartphone/Device/PowerSupply/usb , /org/freesmartphone/Device/PowerSupply/adapter , /org/freesmartphone/Device/PowerSupply/ac : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.PowerSupply /org/freesmartphone/Device/RTC/rtc0 , /org/freesmartphone/Device/RTC/0 : org.freedesktop.DBus.Introspectable org.freesmartphone.Device.RealtimeClock ___ 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
GPU driver/doc development
On ma, 2007-09-10 at 12:08 +0100, Jim McDonald wrote: Not wishing to be contrary for its own sake, but my answer to your (supposedly rhetorical) question would be 'the docs'. If we had a complete manual then that would be enough for other people to write the driver, whereas if we have a driver and no docs then it's going to be next to impossible for the community to add features or fix bugs in said driver and we're stuck with whatever functionality your incredibly small team finds time to implement. You're not being very realistic here. Complete manual would presumably take a lot of time in itself (what with the incredibly small team and all), all the while us having no drivers. Publishing the GTA-02 without much in the way of GPU drivers at all would then delay development of applications that take advantage of said GPU. If they can hack even rudimentary drivers for the GTA-02 release, on the other hand (something only they can do before that anyway), application development can then proceed smoothly from the get-go. 'course, there is a cutoff point where devoting more effort to documentation makes sense, and I am glad it is in the pipeline for the reasons you mention. That point is probably somewhere around where a basic GPU driver is working, and it's time to add more advanced features and tune performance. The definition of basic here is, of course, loose. I'd pencil it somewhere around where rotation, video acceleration and perchance some basic 3d rendering is going on, but I don't mean that to be a solid definition, rather leaving that up to the people who do the work. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
