Re: Please split this list!
One alternative might be to have separate posting addresses which all go to the same list, but result in a short subject prefix being prepended. This would allow group synergies to emerge, while also enable effective client-side filtering. Problems with this approach include : *members who filter won't be part of the synergies. (members who filter don't care about synergies) *some people are passionately against subject prefixes. (there will always be a mixed response) *the mailing list software may not support such a setup (but may does or could be made to, postfix recipes, etc) *possible issue of replys utterly munging the subject (if the message has a know prefix, do not add another prefix) ~ Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Nokia wired headsets compatibility
I tried 4 shops today, looking for an adapter, no luck at all. Mostly blank, unknowing stares. I found/ordered one from ebay, so fingers crossed. While this does not direcly address your problem, the ebay description mentioned a dozen or more devices which the adapter was compatiblw with. Thet may give you a clue as to what headsets will work. I'll post the text it later today. grumble On a less helpful note, I think it's unhelpful of OM not to either sell, supply or link to a suitible adapter. My fault for not researching my options before buying my FR, but who would have thought the adapter would be so ellusive. Of course when the adaptor arrives, what chance of it working (alsa etc). \grumble On 8/26/08, Alberto Morales [EMAIL PROTECTED] wrote: Hi, In this page at the wiki [1] describes the pinout of the headset connector. It also says that the four-ring 2.5mm stereo jack is used by motorola smartphones and the v-360. Both motorola smartphones and v-360 are very difficult to get in stores because v-360 is more than three years old. I've spend today three hours in a dozen stores in my city and i only found one, new but in very bad state, and very expensive (~25 eur). [1] http://wiki.openmoko.org/wiki/Headset Some new nokia mobiles have the same kind of connector. This wiki page [2] says that the nokia 3.5-2.5 adapters doesn't work, but says nothing about nokia headsets. Some nokia headset model numbers with the same plug are: HS-45/AD-54, WH-700, HS-44/AD-44, HS-47, HS-40. Have you tried any of these on the Neo? [2] http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo_FreeRunner#Buttons_and_connectors Thanks ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Sent from Gmail for mobile | mobile.google.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
On Tue, Aug 19, 2008 at 10:54 AM, Neil Brown [EMAIL PROTECTED] wrote: On Monday August 18, [EMAIL PROTECTED] wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. from the man page for gpsd p Returns the current position in the form P=%f %f; numbers are in degrees, latitude first. $ telnet tangogps.org gpsd Trying 82.240.156.91... Connected to tangogps.org. Escape character is '^]'. p GPSD,P=43.739028 7.364333 ^] telnet q Connection closed. 43 degrees north, 7 east. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Isn't gypsy [1] used on some builds? Perhaps build a logger to use either gpsd or gypsy. Gypsy, Python examples are available [2]. Regarding the resulting logs : Would be nice for choose what format; text, xml, yaml, sqlite Start with plain text, with the expectation that someone will want another format. What columns for store, time,long,lat. timezone, time format. ~ Matt [1] http://folks.o-hand.com/iain/gypsy/ [2] http://svn.o-hand.com/repos/gypsy/trunk/gypsy/examples/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO ringtone
I don't mean to be overly critical, the process you've described is trivial enough, and thank you for sharing, but why is is designed like this? Surely if the exact same steps are performed before building the software, it will be much easier for many more people. It just seem insane to be hardcoding references to sound files for functions that people will habitually want to change. Ring tone is probably the first item of customisation a new user will want to change, and they will expect it to be intuitive. On another note, the rule.yaml file looks intresting, where can I find out more about that ? Matt On Thu, Aug 7, 2008 at 12:53 PM, Guillaume Chereau [EMAIL PROTECTED] wrote: Just for your information, with the new events system, it will soon be different. You will have to edit the rule.yaml file. It looks like this now : - # This rule will play a ring tone when a call is incoming trigger: CallStatus() filters: HasAttr(status, incoming) actions: - PlaySound(/usr/share/sounds/Arkanoid_PSID.sid) - StartVibration() - # This one will stop the ring tone when the call is in an other state trigger: CallStatus() filters: Not(HasAttr(status, incoming)) actions: - StopSound(/usr/share/sounds/Arkanoid_PSID.sid) - StopVibration() So you will need to replace the path to the path you want. Still not as good as a real user interface, but better than being hard-coded in the framework code. Charlie On Thu, 2008-08-07 at 01:53 +0200, Francesco Cat wrote: add this on the wiki :D it seems nice and should be automated in a really simple way! :) 2008/8/7 Angus Ainslie [EMAIL PROTECTED]: On Wed, Aug 6, 2008 at 3:40 PM, simarillion [EMAIL PROTECTED] wrote: On Wednesday 06 August 2008 20:20:29 Angus Ainslie wrote: Where is the FSO ring tone saved ? Angus I think it's /usr/share/sounds/ But I'm not sure. Thanks , Thats exactly where it is. /usr/share/sounds/Arkanoid_PSID.sid Now to change it is a little bit of fun. first in /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.py Change the line that reads: decoder = gst.element_factory_make( siddec, decoder ) to decoder = gst.element_factory_make( mad, decoder ) and change the line that reads: filesrc.set_property( location, /usr/share/sounds/Arkanoid_PSID.sid ) to filesrc.set_property( location, /usr/share/sounds/ringtone ) Then mv /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.pyo /home/root then reboot the phone ( I'm sure there's a better way to regenerate receiver.pyo but I don't know it ) Now you can link /usr/share/sounds/ringtone to any mp3 and that will be your ringtone Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some commentary on the new Openmoko direction, and a review of FSO
Between Kevin Dean's commentary and Wolfgang's response, there's more information than can be found in a day of trawling threads and rummaging in the wiki. Bravo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO: settings and profiles
On Fri, Aug 8, 2008 at 8:36 AM, Fredrik Wendt [EMAIL PROTECTED] wrote: And there is a profile switcher planned I hope? I just can't let go of the idea of having several profiles activated at the same time, so I'll spam you all once more (last time, I promise). Locations: - work - home - cinema - lecture hall - hospital - amusement park Activities: - coding (default) - none (default for others) - meeting - in a phone call - lecture / conference - watching a movie - exercising (biking anyone?) (it could detect the wii fit bluetooth MAC addresses in the air as well) Time based: - after bed time - tuck in time (put the kid(s) to sleep) - lunch - working hours - Simpsons Other: - phone is upside down on a table (only flash lights, no buzz or ringtone) - battery is running low - far from home (send e-mail with GPS coordinates every hour) - vacation (don't send GPS coordinates every hour) - bluetooth headset is in range (and paired) - home media center (and asterisk) is in range (redirect music) Being able to have just _one_ context/setting/mood at a time is so restricting. When I go to lunch (12-13, or 12 am to 1 pm) I generally put the phone in my pocket so I want the ringing sound to be louder. BUT, if I'm in a lunch meeting with a client (the meeting's in the calendar) I don't want to be disturbed (except by family and day care numbers), hence there should be no ringtone at all. This is also true while exercising (louder), unless it's tuck in time for the kids and I'm at home (Wii Fit). If I'm at the cinema the GSM should turn off, unless I'm at a conference (in my calendar) which would only turn ringtone off (or send it to my BT headset at a low volume). If I'm a presenter I'd like all calls to be rejected (unless family + day care) so I won't be interrupted while using the FreeRunner as a remote control (next slide, etc - too bad it didn't come with a laser beam/LED as well :). I'd love the idea of having more than one profile (context) active at the same time - my daily life simply isn't that simple that one profile fits. I don't want to be locked up in old locked down cellphone behaviour - I want to be free. ;) / Fredrik Wendt Much of what you have described was articulated in this [1] thread, including profile aggregation. I strongly encourage people to post their similar ideas so hopefully developers will be able to anticipate future requirements. With regards to applying multiple profiles (which I really like), some thought will have to go in to resolving conflicts. For instance, if we have two rules : On location event set profile foo; On temporal event set profile bar; The profile may be opposites, if they trigger at the same time, which should win out ? [1] http://lists.openmoko.org/pipermail/community/2008-July/thread.html#22447 Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FSO oeventsd and rules
On Thu, Aug 7, 2008 at 12:53 PM, Guillaume Chereau [EMAIL PROTECTED] wrote: Just for your information, with the new events system, it will soon be different. You will have to edit the rule.yaml file. It looks like this now : - # This rule will play a ring tone when a call is incoming trigger: CallStatus() filters: HasAttr(status, incoming) actions: - PlaySound(/usr/share/sounds/Arkanoid_PSID.sid) - StartVibration() - # This one will stop the ring tone when the call is in an other state trigger: CallStatus() filters: Not(HasAttr(status, incoming)) actions: - StopSound(/usr/share/sounds/Arkanoid_PSID.sid) - StopVibration() snippaste Well, it is very new, I just added this to the framework a few days ago. It uses the yaml syntax [0] that I like a lot . If you want to see the code, download the framework daemon [1], and have a look at the files in subsystems/oeventsd/ It is all in python and there is enough documentation to get the idea. As soon as the framework team accepts this thing, I will create a tutorial on how to create custom rules in the freesmartphone wiki [1] [0] http://www.yaml.org/ [1] http://git.freesmartphone.org/?p=framework.git;a=summary [2] http://www.freesmartphone.org/index.php/Tutorials Am I right in thinking that oeventsd [1] is essentially a rules engine, looks that way. So, for instance, to implement the feature 'change ringtone depending on caller'. 1. Would ophone look up the callerid in contacts for a ringtone, and pass it to oeventsd to be handled by Playsound? 2. Or will oeventsd be the brains, taking the callerid and processing the rules, which may involve factoring in time, location, contact, contact group memebership, etc, and initiating the most appropriate action? (play sound, hangup, divert, answer and play message, start recording) 3. Or might oeventsd hand off to a separate rules engine altogether? This would allow others to write their own dbus compliant 'rulesd' in whatever suits them (prolog, lua, etc). Interesting times indeed. Thanks [1] http://git.freesmartphone.org/?p=framework.git;a=tree;f=framework/subsystems/oeventsd ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM detection/identification
On Mon, Aug 4, 2008 at 11:47 AM, Esben Stien [EMAIL PROTECTED] wrote: Paul Buede [EMAIL PROTECTED] writes: What I need now is a way to pass commands from the cli and have it return values to the cli rather than operating in the shell. What you want is a non interactive interface to the gsm daemon and I'm very surprised it's not implemented this way. `libgsmd-tool -m atcmd` outputs results to stdout. (tested on 2007.2) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM detection/identification
On Thu, Jul 31, 2008 at 10:38 AM, Paul Buede [EMAIL PROTECTED] wrote: Anybody else know what I can query or run to view available cell carriers at any given time? Is this even possible? Correct me if I am wrong, I am kind of making this up to try and figure out how it works: I had a play last night, I was trying to find out what towers were contactable. I wasn't successful, but you might be with your investigations. The wiki has some interesting info on GSM : http://wiki.openmoko.org/wiki/Gsm The AT commands to interact with the hardware are here : http://wiki.openmoko.org/wiki/Hardware:AT_Commands (I wonder if they are an extension of the earlier dial up modem commands ala Hayes?) here's how you use the commands: http://wiki.openmoko.org/wiki/Gsmd#Usage_of_shell_mode these command may work for you : r Register to network R Register to given operator (R=number) U Unregister from netowrk P Print current operator N Print current operator in numeric L List available operators Q Read signal quality nr Query network registration As I mentioned, I wanted to find all contactable sites, but didn't find a command for that. Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
It would be good to make sure that it's easy to have prolog or some other rule based system autogenerate and interface to the small domain specific language. I think the way it would work is prolog would use some event handlers to maintain a table of facts that the DSL would then use as its base database. Also, datalog would be a much better choice than prolog. The outcome of prolog programs depends on the order in which rules are defined. This isn't true for datalog, which has cleaner semantics. The two languages have nearly identical syntax. -Rusty I took some time to read the wikipedia pages for bother Prolog [1] and Datalog [2], both interesting. I found some Prolog libs for Python but not for Datalog, but I found source code for Datalog - A deductive database system for memory constrained devices. [3], a quick look suggests it written in C. Might be interesting. I think it's important to keep jotting down potential uses for this system, I think I may whip up a wiki page at some point. With inference in mind, a small gui app which simply asks Where are we now ? The user enters Work, or Home, etc. The app informs the rule system about all the GMS towers it can detect, and WIFI networks and the tag the user entered. A pretty simple way of training the system, I think. How about a location based home pages on the browser or rss. I'm at the station (because the rule system infers that I am), show me the traffic news rss. At work, show me my Nagios status page. At home my weather station page. (is that sad?) Anywhere else, google please. I'm pretty sure GSM locations would work for this sort of thing. Comments welcomed. Regards Matt [1] http://en.wikipedia.org/wiki/Prolog [2] http://en.wikipedia.org/wiki/Datalog [3] http://www.ccs.neu.edu/home/ramsdell/tools/datalog/index.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruleby was: Rules based policy engine
Tilman Baumann wrote: Scott wrote: I just found this inference engine. http://ruleby.org/wiki/Ruleby I working on a Rails project think Ruby is a great language to work with. And Ruby is pretty small.. A bit too many layers there for my taste. :) A domain specific rules language implemented in ruby embedded in c? The ruby layer does not seem to be thin enough to justify that. (ok, writing rules in ruby is kind cool. As would any other real language be. Like lightweights like lua or certain lisp-ish languages. Even javascript would not be bad.) Btw. I like the idea of a rules language. But why not something simple and stupid like for example SIEVE filters in cyrus imap. That's a hand full of yacc and lex magic and some stupid engine code. I mean, what we can match is pretty much defined by the fact that we match numbers and SMS. A hand full of logic expressions on pre defined attributes should be enough. My email filter is not smarter too, but email a lot more complicated. And it works well. If someone puts the effort in to something like Prolog or Ruleby i will not argue. But it seems a bit overkill to me. I agree with Rusty's idea (somewhere in this thread), if it's built as modules, the rules processing could be done by various efforts. Python, Ruby, Sieve, Prolog, Datalog, C; how fantastic that we have the chance (and choice) of any (all), including those we haven't thought of yet. Fertile times indeed! For some (me) the FR is a toy of sorts, something to explore. For others it's a tool, something to solve a problem with. I suspect it's partly an act of rebellion too. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Wed, Jul 23, 2008 at 6:41 AM, Frederik Sdun [EMAIL PROTECTED] wrote: Hi, I'm one of the GSoC students and work on the answering machine. I already use this concept in my project and it uses modules so it might be possible to extend it to fit your needs. It's implemented in vala so you can use all GLib functionality and more. As far as you can create vala bindings for it or you can use C and GObject. I just implemented 2 types of connecting rules yet: all of them or one of them. Also a complex type might be possible. my current rules are: -time ( depending on day of week and current time) -calendar ( depending on your entries in you calendar ) -GPS ( depending on a GPS position and a radius around this ) my current actions are: - run a custom command on startup and at the end - answer call: yes it is an answering machine - answer asterisk call: this should also be answered - send sms: send a user defined message to a caller Here you can find the class diagram [1]. it will be updated soon. Regards, Frederik [1]: http://v1187.ncsrv.de/classes.jpeg Frederik, Can you explain how/where you define the rules? Also, how are you gathering event information? Thanks Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wiki database error
I also got an error, trying to save a minor change. Database error From Openmoko Jump to: navigation http://wiki.openmoko.org/index.php?title=Supportaction=submit#column-one, search http://wiki.openmoko.org/index.php?title=Supportaction=submit#searchInput A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function SearchMySQL4::update. MySQL returned error 126: Incorrect key file for table './wikidb/searchindex.MYI'; try to repair it (localhost). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
I'd like to see a diagram showing how you envisage this fitting together. Somethings like : App1=D=[event handler, current states]=[rules engine]=[rules]=[rules gui] App2=B App3=U App4=S I'm not clear on the existing role or use of DBUS, are existing apps (gsmd, gps, mplayer, contacts, clock, diary, etc) already DBUS aware, do they publish their events, or states queried? Matt On Tue, Jul 22, 2008 at 4:27 AM, Russell Sears [EMAIL PROTECTED] wrote: I fell out of this discussion for a while, but I'd much rather see a very simple C API that delivers events from DBUS with bindings for python / your favorite language. The event system and programming model (rule based, prolog, python, ...) should be completely separate modules. That way, you don't need to design your application around being able to receive external events. Also, if we couple the event system to the programming language, then all other languages become second class citizens. That would suck. I'd like to clarify my original post. (Also, I still haven't looked at D-BUS, it might already do most/all of this stuff.) These two lines are meant to be function invocations, perhaps in C or in python: register_event_handler(/phone/incoming_call = true, mute_music_callback) register_event_handler(/clock/time = 600, play_alarm_callback, loud_buzzer.ogg) register_event_handler() should be a C function that takes three arguments: 1: A char* containing a query written in a small domain specific language. I don't think we need support for more than: a) =, , , ... b) Conjunction + disjunction; and ||, which means all of or one of these rules match The following two would be nice, but might make things harder to implement: a) Parenthesis for grouping b) Negation xpath is a well-known language, and is close, though I don't know how well existing implementations deal with events (ie: third parties making changes to the underlying xml document). Also, I think xpath is probably too complicated. 2: A function pointer of type void (fcn*)(void *) This gets invoked when the evaluation of the query changes from false to true. 3) A void * The application program controls what goes in the void*. Applications should be able to build all sorts of things with these primitives, including new domain specific languages. It would be good to make sure that it's easy to have prolog or some other rule based system autogenerate and interface to the small domain specific language. I think the way it would work is prolog would use some event handlers to maintain a table of facts that the DSL would then use as its base database. Also, datalog would be a much better choice than prolog. The outcome of prolog programs depends on the order in which rules are defined. This isn't true for datalog, which has cleaner semantics. The two languages have nearly identical syntax. -Rusty Chris Wright wrote: 2008/7/20 Ryan Meador [EMAIL PROTECTED]: I think it's important that we use an existing general-purpose platform such as Prolog (at least, it's about as general purpose as logic programming gets...). I would favor Rhino.DSL, simply because I know it integrates well with a language with dbus bindings. And because it can probably result in very readable syntax. And it's based on Boo, which is very nearly Python, and thus more accessible to most programmers than Prolog. Does dbus allow you to specify your priority when listening to an event, and to prevent it from being published to other listeners? If not, then the first step is to separate the relevant dbus events and come up with an application that merely translates unconditionally between the two. And that allows you to insert any rules engine you want. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Scott Derrick wrote: If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot That's a valid point. However, if a GPS dependant rule cannot get a fix (because it's off) in a timely fashion, the rule fails. It may be possible to use GSM call towers to give a good enough location for these rules. Looking at this rule again : 'If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls.' 'reliably' is the operative word here, and I may consider GSM based location, reliable. If a profile switching approach is taken, we could switch to the vibrate with exceptions' profile and shutdown GPS. On the other hand, if always-on GPS is what's needed, then future models will have to address the power requirements. Or, perhaps a case mod for larger batteries is required. Presumably geo-mappers have this problem already. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Or, perhaps use GSM triangulation to trigger GSP fix acquisition. Scott Derrick wrote: I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. Scott matt joyce wrote: Scott Derrick wrote: If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot That's a valid point. However, if a GPS dependant rule cannot get a fix (because it's off) in a timely fashion, the rule fails. ___ 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: Rules based policy engine
arne anka wrote: It may be possible to use GSM call towers to give a good enough location for these rules. a gsm cell is usually much bigger than most restaurants -- and gps might not be available inhouse. btw: a rule that analyses calendar entries and depending of the character of the appointment disables ringing might be sensible. thus i only have to select the importance/category of the appointment and not to worry about forgetting to disable the phone. I agree. An extensible rules system which others developers can hook into would allow for this. The user might just select a phone profile (Do not disturb, except...) when they set her calendar appointment, and a rule can be generated, without the users becoming a programmer. A rule might exist, set profile whenever I meet with this contact, and the profile is auto-selected when the appointment is made. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Sorry, I should have been clearer. What I meant was, if the rule engine/event broker has geo defendant rules, it could use GSM towers to ascertain if a GPS fix is required. This (or other checks, such as calendar, time) can happen prior to any voice/message events occurring, gsmd would just check for blocking rules (absence of) on event. Matt On Mon, Jul 21, 2008 at 7:51 AM, Scott Derrick [EMAIL PROTECTED] wrote: Problem there is the rule based engine is trying to decide to answer the call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60 seconds for a cold start fix from the GPS is too long. Scott matt joyce wrote: Or, perhaps use GSM triangulation to trigger GSP fix acquisition. Scott Derrick wrote: I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. -- The only security of all is in a free press. The force of public opinion cannot be resisted when permitted freely to be expressed. The agitation it produces must be submitted to. It is necessary, to keep the waters pure. Thomas Jefferson to Lafayette, 1823. ME 15:491 ___ 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: Rules based policy engine
On Mon, Jul 21, 2008 at 11:08 AM, Ryan Meador [EMAIL PROTECTED] wrote: matt joyce [EMAIL PROTECTED] writes: Ryan, what approach have your efforts taken already? Any interesting insights to the problem? Matt My efforts as far as applying my inference engine to the OpenMoko platform basically consist of a few ideas rattling around in my head -- nothing concrete. I'm not a professional at this stuff, just an enthusiastic amateur trying to follow in the footsteps of some of the very interesting early AI research projects (most inference-based approaches to AI died out in the 80's, but a few are still around). To that end, most of my work has been focused on things not directly useful to a phone platform. I think it's important that we use an existing general-purpose platform such as Prolog (at least, it's about as general purpose as logic programming gets...). This saves us from reinventing the wheel and also prevents us from thinking ourselves into a corner -- a general purpose system will likely be much more extensible and flexible for powerusers (and with this device, who isn't?) than something we dream up. Taking an inference-based approach to setting up the rules in the phone could allow us to create rules that are more abstract than most of the examples I've seen on this list. Instead of telling it don't use the ringer when I'm at the office, it could be don't use the ringer when I'm doing work. Work would be defined by other rules, such as your proximity to the office, whether or not you've scheduled an appointment in the calendar with contacts from work (think lunch meeting), and if you have a deadline that isn't marked as complete and it's only an hour away (you're probably workign furiously to meet it). That's just an example I created just now, and not particularly good -- good examples are hard to think of, but that's largely because the possibilities are endless. As one other person on the mailing list noted, the possible configurations of the rules engine that are nonsensical outnumber the meaningful ones by millions to one :) That babbling probably wasn't very helpful to anyone, but maybe it will at least build enthusiasm. I think the gist of it was mostly this: make it more flexible than it needs to be, and also make the rules capable of building on top of each other to create more complex conditions. Just my $0.02 :) Ryan I find myself in a real quandary about this. On the one hand I want more flexibility, more inputs, more actions and such, because I feel creative uses will emerge from that. On the other hand my experience as an IT practitioner and technologist, instinctively tells me to keep it simple. I've spent most of my IT career trying to remove or prevent unnecessary complexity. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: In the press. The OpenMoko wiki - a tangled pile of mostlyoutdated and incomplete documentation.
Yes. http://lists.openmoko.org/pipermail/community/2008-July/022628.html Josh Monson wrote: Has the list been created? The wiki-editors mailing list? Michael/Brenda, Is there any type of organizational plan at this point in terms of whom will be doing what, and will Brenda be coordinating the efforts I assume? I know this has all come up very quickly so it's totally understandable if there is no plan as of yet :P. Just trying to get coordination rolling. Cheers and thanks again -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steve Sent: Thursday, July 17, 2008 6:24 PM To: 'Steven **'; 'List for Openmoko community discussion' Cc: 'Brenda Wang' Subject: RE: In the press. The OpenMoko wiki - a tangled pile of mostlyoutdated and incomplete documentation. The issue is the wiki grows like a weed. On one hand this is great since information just get posted. On the other hand this rhapsodic construction is difficult to navigate. So... Solutions welcomed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven ** Sent: Thursday, July 17, 2008 1:29 PM To: List for Openmoko community discussion Cc: Brenda Wang; steve Subject: Re: In the press. The OpenMoko wiki - a tangled pile of mostly outdated and incomplete documentation. I'll tell you explicitly. Go ahead. It's a wiki! If anyone doesn't like your change, they can easily see the history and revert it. Or just clean up your change however they like. That's what makes the wiki so powerful. If they didn't want you to edit it, I'm pretty sure they could lock it down so that you can't. The fact that they haven't seems to mean they aren't worried regular users might edit it. -Steven On Thu, Jul 17, 2008 at 3:19 PM, Stroller [EMAIL PROTECTED] wrote: Hi there, I thought to try fixing a small part of this particular problem by editing the main page adding a link to http://wiki.openmoko.org/ wiki/Distributions But I do not see where to put it! Perhaps it should replace the Current software stack link to http://wiki.openmoko.org/wiki/ NeoSoftwareStack ?? Perhaps these 5 categories: Introduction to Openmoko Openmoko Products Join Openmoko development Openmoko community Getting started with Openmoko Wiki should be extended with the addition of Openmoko software? Or perhaps I should just get my hands dirty and change the Introduction to Openmoko to include the link to Distributions? As a user I feel reluctant to edit the main page as I feel it belongs to Openmoko the company or to Brenda, so you must tell me explicitly if you wish me to feel free. Stroller. On 17 Jul 2008, at 20:00, steve wrote: Brenda The main page index does not address Scotts issue. I second scott's criticism of the wiki. It is not organized well. A good start would be a better search engine Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Wang Sent: Thursday, July 17, 2008 6:56 AM To: [EMAIL PROTECTED]; List for Openmoko community discussion Subject: Re: In the press. The OpenMoko wiki - a tangled pile of mostly outdated and incomplete documentation. Hi, I am wiki full time editor of Openmoko. Thank you for your opinion . I will put more effort , to make wiki more easy to use. And now , If you want to know what we have on wiki , Please use this Index page. http://wiki.openmoko.org/wiki/Main_Page Brenda Scott Derrick ??: Perhaps this is what you seek? http://wiki.openmoko.org/wiki/Distributions This is a great page, one of the gems hidden in the bowels of the OM Wiki. Its also a great example of whats wrong with the Wiki. But how do I find it? Its not listed on the home page, not on the FreeRunner page, not on the getting started page?Unless I search for exactly teh right word or combinations of words I would never know it existed... The only link I could find, after I knew it existed was Software/distributions/distributions.. There has to be some kind of boiler plate format for the design and layout of the Wiki so things are easier to find. You can't rely on the search engine, it sucks.. I think that was the point of the person who recommended the OpenWRT Wiki. Its design and format was easy to use and helped you find things instead of thwarting you. Scott ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list
Re: Dot'n reply above quote
arne anka wrote: imho the number of people adverse to top postings equals more or less the number of people being annoyed by down-postings. just recently i got mail over 4 pages (with a screen 19200x1200 and 11px font!) with just one (and above all rather meaninmgless) sentence below. ususally i know from the subject and a short glance a) what the thread was about or b) if i am inclined to read the mail. Agreed. this top/down is not going to solve anything ... there are imho two rules to be observed instead: - use meaningful subjects - quote only what is absolutely necessary A little common sense and curtsy, go along way. and btw: for the sake of future generations and the archive: _never_ do something like oh! i found a solution! it's here: http://someoutsideurl. bye there is little more annoying but searching the archives for a specific problem, hitting a solved-post and seeing it points to a dead link w/o citing the solution! A third must have rule should be; don't be lazy start a new thread. Top/Bottom might annoy some people, but thread-jacking has a lasting consequence. It really is an irksome practice. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reply above Quotation
Mike wrote: Scott Derrick wrote: If your going to quote the email your replying to, please reply above the quotation. Its hard enough wading through 300 emails a day without having to page down to see the reply. Scott Are you with openmoko?? Do you have any authority? You don't have an openmoko address. Authority?! You have to be joking. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reply above Quotation
OK so let's take this to the extreme- if I were to post something like From now on, the official rule is, no one can use the word 'code' on this mailing list. You would be wrong to ask me if I had any authority, right? No, I would just ignore it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting portable keyboard
Jörgen Lidholm wrote: On Sat, Jul 19, 2008 at 7:31 PM, Ron K. Jeffries [EMAIL PROTECTED] wrote: just saw this reference to a small keyboard that may work with Freerunner. http://theburtonreport.blogspot.com/2008/06/ultra-slim-mobile-keyboard.html Comments? Quite nice keyboard, rather slim. Wonder how it feels to type on. Have a look at this one, http://www.senseboard.com/ /Jörgen It might be great, but the acolade is 'Best of COMDEX Fall 2001', and I have not heard or seen of it in the last 7 years. The palm in the photos is seriously obsolete. Ok, perhaps they aren't great at marketing. There is a 2008 development system, so I suppose it's still a current product. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Ryan Meador wrote: Steven Kurylo [EMAIL PROTECTED] writes: The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. I think what we're looking for here is Prolog (or something very similar). http://en.wikipedia.org/wiki/Prolog. I'd be very interested in contributing to (and using!) a rule-based system such as this. In addition to providing an inference-based rules engine written in first order predicate logic, it has the unique ability of adding rules with side effects (basically executing native code) when certain things happen... I think it would work nicely (it basically is for this purpose). I already had plans to create a rule-based system for the moko myself (an adaptation of a prolog-like inference system that I already have under construction). Due to the memory and processing constraints on the moko and the desire to reuse code whenever possible (which I agree with wholeheartedly), I think going with Prolog is probably a better choice than trying to finish my hacked-together and unproven inference engine. Now if only my Freerunner would arrive... dunno why it's been delayed by a week before shipping. Ryan Meador __ Ryan, what approach have your efforts taken already? Any interesting insights to the problem? Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Guillaume Chereau wrote: This is one of the thing I am planning to add in the framework (FSO project), although for the moment we don't focus on it too much. I agree with Alexey as well, the danger is to create something so configurable, that at the end your setting become a python script. My idea for the moment is like this : You can define a set of condition to specify the profile. For example : if at my girl friend house, profile = Paranoid Then you the application configurations can depend on the profile. e.g : If profile is Paranoid, girl_friend_number_2.block_calls = True This way, the profile is the link between the conditions set and the actions set. The number of profiles is not supposed to be too large. It is more restrictive that Russel idea, because you can't say : if time = 600, then play alarm. The only way to do so would be : if time = 600, then profile = RunAlarm if profile is RunAlarm, then alarm.run = True Which is not really useful, you don't want to create one profile for every events combination you can think of. I can see several cases where this way of doing is not the best, but I still think it is the most suitable for most practical cases. -charlie Profiles, recipes, rulesets; I think we all talking about the same thing, behaviours. It boils down to detecting a set of conditions and instructing the phone to behaviour in a certain way. Profiles are an excellent way of describing a group of common phone settings. (settings the call handling services already respect) People are familiar with the concept, they could be described by setting a phone using normal method and saving them. Perhaps if there was a default profile, and we only store differences, the delta, in other profiles, we could have cumulative profiles. That might help with the tedium of setting up every permutation and keep the number of profile down. Profiles are really just a bunch of SET actions. I still see the need for an event broker of sorts, something that will detect conditions and trigger actions. Perhaps the profile switcher (as some else mentioned) could be enhanced for that purpose. An alarm might just be a custom action, just another action. 'Run a shell command' might be the only action we need. Another poster mentioned interacting with his MythTV, one approach might be to configure the MythTV to run web server with some cgi. The phone would just use http to instigate commands. wget? If we had profiles and an event broker, all we need next is some standard way to describe the set of conditions. I'm no hardcore coder, but it seem well within the realms of possibilities. I still favour a scriptable solution, even is it wrapped in UI and machine generated. Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
However, I would've thought that if every application can generate and consume 'events', then all that is needed in your policy app is the ability to look for combinations of events (and/or states?) and generate new events that other apps can pick up? Is that what you were thinking. Yes. This has the downside that all of the 'intelligence' is in an external script/rules engine and not in the apps. That might be an 'upside'. Alternatively, each 'rule' could be it's own script which waits on certain events and then fires out new events that are picked up by the other applications to do things. As I see it the trouble with each rule being an isolated process, or script, is that conflict detection might become a bit of a headache. Love the idea, though. Cheers Alex. Thank you Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: In the press. The OpenMoko wiki - a tangled pile of mostly outdated and incomplete documentation.
AVee wrote: On Thursday 17 July 2008 23:35, Dotan Cohen wrote: 2008/7/17 Brenda Wang [EMAIL PROTECTED]: Hi, I am wiki full time editor of Openmoko. Thank you for your opinion . I will put more effort , to make wiki more easy to use. And now , If you want to know what we have on wiki , Please use this Index page. http://wiki.openmoko.org/wiki/Main_Page Brenda I'm going to upset some people with this post, but I think it's necessary. When I speak English, I make a conscious effort to be clear and to use correct grammar. That is because when non-native English speakers must communicate in English we often have trouble with the sentence structure and lack of gender to identify subjects. I think that whoever maintains the wiki should have a very firm grasp of English grammar. Not necessarily a native speaker (as they often have bad grammar in my opinion, probably because they have no trouble deciphering the meaning of the sentence anyway). I mean no offense, Brenda, but English with Asian grammar (I'm assuming Asian based on the grammar style and your last name) is very difficult to read and understand. I hope that my criticism is seen as constructive and not personal, because I mean no offense yet I'd like to see the wiki maintained by someone more qualified. I think you do raise a valid point. However, I also think it perfectly ok to seperate the purely content related redaction from the linguistic issues. As far as I can see there is absolutely no problem with the content itself. Maybe someone should proofread it before it's posted. Or after it is posted, it's a wiki after all, you really should just correct any errors you find. AVee We should encourage people to dump their knowledge, if it's accurate, it's valuable.Spelling and grammar are quick edits. I would hate to think someone wants to contribute but doesn't because they feel their language skills aren't good enough. Useful content will attract more eyes, which in turn will improve the likelihood of errors being spotted. I for one, am a shocking typist and have appalling spelling but my grammar is reasonable. Hoorah for little red lines under words. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Rules based policy engine
I have always wanted many more features on my phone, than any phone I've owned has provided. I expect the majority of people who are excited about Openmoko have similar day dreams. I'd like to propose a rule based policy engine. In essence this would be an event based system, a service that other services could refer to, to influence their behaviour. These devices are inherently personal, just as other computing devices are, so it reasonable to expect everyone will have slightly different requirements. The problem with a great many people wanting specific features, or personal requirements, is that some will be realised and some will not. Some requirements might be very similar, but not quite right, and some features may compete unproductively, clash. By creating a rule based policy engine, I think it would be possible to give the user the ability to describe the way their phone should work, for them, without each feature being developed for them. Here are some examples of how I would like use this concept to make my phone more personal, and how I would like to teach my phone to be smart. If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. Some rules would be permanent, some would be one off If John's phone is detected via bluetooth, please let me know (I need to see him, when he comes in.) Do not disturb until 13:00 (I need to get some work done) No calls until this contact calls me (I'm expecting an urgent call) Loud volume for the next hour (It's noisy here) Silent for an hour (meeting) Some events might be : - In/out calls, sms, emails - Arriving/departing somewhere - Enter/leave a time period - Discovery/loss of a bluetooth device (infer person is nearby/left) - Discovery/loss of a WIFI Similarly ,states which could be queried might be : - Call in progress - Location is within a defines area - Time is in a period - Battery is low - USB is connected Some definitions - Groups of contacts - Lists of GPS co-ords - time periods Some actions - Answer/Don't answer call - Set volume profile - switch on/off - start/stop an application - manipulate hardware It would be quite similar to rule based filters many email systems use (outlook, thunderbird, gmail, procmail), or firewalls for that matter. Who knows, perhaps it could learn and suggest rules based on behaviour. I'm sure creative people can explore and extend this idea. Does anyone think this has merit, is achievable and worth pursuing? Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Fri, Jul 18, 2008 at 9:59 AM, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce [EMAIL PROTECTED] wrote: If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Programmers are people too. :) Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. Yes, this is precisely what I want, although it need not be overly complex. Thunderbird's filter system is easy enough, MokoRules would be more complex, but the process can be broken down into small steps. http://opensourcearticles.com/nidelven/website/articles/thunderbird_15/english/part_07_images/1126606659X51 I've always thought Outlook's rules wizard was pretty good. http://pubs.logicalexpressions.com/pub0009/LPMArticle.asp?ID=415 I'm frequently impressed by non-technical staff at work, who write rules to make their outlook work for them. Moreover, if one *is* a programmer, and has learned the rule expression language, there will be bugs in the rulesets, like overlooked priorities or excessively permissive conditions, and you'll spend some time debugging it, probably missing a few important calls and alarms now and then in the process. Next step would be debugging tools for rulesets, allowing to simulate times of day, different conditions and incoming events to test the rules. Next, backup and revision control for rulesets. This is where madness lies: you have to modify and debug a program in a declarative logic language when you start dating someone because it breaks all your carefully polished ruleset. Agreed. This is about granularity, and the examples I gave were off the cuff and may well be unworkable in RL. Sanity check can be developed too, and packaged in groups to meet the needs for Novice, Competent, Pro. Freedom to make mistakes. Sounds like a topic for XKCD. Randall, are you by any chance reading this? I know what you mean. I understand that you must be thinking, This phone is fully programmable, so I can make it do whatever I want. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: Here is a computer. You can program it to do whatever you want. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with their cell phone), it's not a killer application. It's an absence of application; it's rather an interpreter for a programming language in which a user can write themself a killer application. Yes, that's what I want, I'd be happy with text config files to start with. Even an offline webapp to make/test the rules, is not disagreeable to me. People could publish their recipes, rulesets. The key to making a phone do what you, I or someone else wants is rather in analyzing our requirements and figuring out what parts are constant and what are changing. Of course, all people want different things, and the same person wants different things at different times. But the number of dimensions in the space of all reasonable people's demands is still much less than that of the space of all possible rulesets. Only a small subset of all possible rules, let alone rulesets, makes any sense at all, while the vast majority is nonsensical, such as When WiFi is available and John's phone is nearby, mute all calls, or If I have unread SMS on Thursday, prefer GPRS. Analyzing and isolating the axes of user demands is much harder than developing a ruleset-driven engine, but at least it has a chance of becoming usable. This reminds me of a Richard Dawkins quote, speaking about the search space of DNA, But, however many ways there may be of being alive, it is certain that there are vastly more ways of being dead, or rather not alive. I think what your saying is that the more variables there are, the more possibilities of non-useful, or counter productive rules there will be. If you are, then I
Re: Rules based policy engine
On Fri, Jul 18, 2008 at 11:55 AM, Steven Kurylo [EMAIL PROTECTED] wrote: The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. Sieve - http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language) xpath - http://en.wikipedia.org/wiki/XPath ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki search
Perhaps it's the databse config, not the wiki. http://kb.ucla.edu/articles/configuring-mediawiki-to-search-for-three-letter-words BrendaWang wrote: Can you give me the more information about modify the configuration ? That will be great help. Thenks Brenda Sven Klomp ??: Dear Brenda, please modify the configuration of the Openmoko wiki, so queries with less than four letters can be found. It might be helpful with all the abbreviations like ASU, FSO, SHR :-) Thanks Sven ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OM's wiki be used offline?
That look so neat. john wrote: A project I was on had a similar requirement of being able to search and read documents offline on the iPhone *snarl*. Anyway, what I did was port an excellent open source search engine called hyper estraier [1] over to the iPhone and used that on various kinds of documents. As a test I indexed over 2000 PDFs from MIT OpenCourseWare. It works really well [2]. I used lighttpd for the web server. All these technologies will work fine on the 1973/Freerunner. If there is an interest in this I could package it up for Openmoko. There is also potential for developing a native GUI local search tool using hyper estraier because it comes with a C API and other language bindings. This would remove the web server dependency. John. [1] http://hyperestraier.sourceforge.net/ [2] http://www.youtube.com/watch?v=MKKlkcZ6vYo 2008/7/14 Yaroslav Halchenko [EMAIL PROTECTED]: Hi All, In the sight of upcoming delivery of our 10-pack, we wanted to get ready to do some testing on the spot, ie when we get together and open our boxes, to power then up and try to make sure that all of them work in the 'similar' fashion (GPS, GSM, etc) so if there is a defective unit, we could localize it easily since we will have a few of them and a few of SIM cards to try ;-) But if smth doesn't work, of cause, the best way is to lookup on the wiki and we will not have (I think) internet connection on the spot. I thought if it is possible to gently (smth not like wget -m http://www.openmoko.org) obtain a copy of openmoko.org's mediawiki content. Brief googling lead me to few possible solutions (unfortunately not non-intrusive into openmoko's wiki setup) such as Mediawiki offline (thanks to Google Gears): http://wiki.yobi.be/wiki/Mediawiki_LocalServer But I wonder may be there is simpler/better ones like a dump of DB without account information credentials, etc? Something like what wikipedia offers http://en.wikipedia.org/wiki/Wikipedia:Database_download (which they actually closed and I see the reason with their sizes), but they also seems to have a workaround http://meta.wikimedia.org/wiki/Wikix -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: In the press
On Tue, Jul 15, 2008 at 2:47 PM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: Jay Vaughan wrote: This stood out for me The tangled pile of mostly outdated and incomplete documentation at the OpenMoko wiki... Is this an accurate evaluation of the wiki ? If so, what can we do to fix it up, how do we identify old content and schedule it for updating? I think, personally, its time for a 3rd-party site not related to OpenMoko to pick up the slack here. So much stuff happens too quickly for people who /should/ be updating the wiki to feel like its productive to do so .. What I would like to see is something like an mokofanboix.org website come up that has the following: - Daily blog news akin to the good ol' slashdot, of news from the openmoko scene, gleaned from careful inspection of the mailing lists, of IRC, of the codebase, of code delta's, etc. - Public free Repository of all the latest and greatest 'cool apps' found for OpenMoko - Public forum for discussion of the news. This is, of course, sorta what we've got with things like planet.openmoko.org (which I check daily), combined with the Scaredycat repo's and other such things, but .. for newcomers .. I don't think any of this is as easily approachable as it would be if it were all put under a single umbrella that is a bit more of an 'openmoko pop culture' site than what we've got right now .. Jay These are all great ideas and would be very helpful for us. We are a small company. And really try to focus all we can on our products. Community help to make these more approachable is something that would make us all very grateful. Let me know if there is anything specific you think we (Openmoko) could do to help get this all started. -Sean My take on the problem is that if a new user searches for information, and finds something promising but it turns out to be wrong, or out of date, they will probably not update it. Once they find the information they may not remember (or be inclined) to go back and update it. What new user is going to start off by editing an article about stuff they don't know? Perhaps one method of identifying information, it to have a simple way to flagging an article as 'needs checking'. Wiki moderators and the community at large could focus their efforts there. MJ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Firstly I don't have much of an issue with the way things have been handled so far. In fact the closeness of the users, the community, the developers, the engineers and management, just strengthen my resolve that Open Source phones are the way to go. (I'm finding the resolution process fascinating. Really quite thrilling.) With regards to disseminating official information such as the various useful posts from Joerg and friends, I think posting to an official Openmoko blog would be better, and then posting links to the blogs on the lists. As good as lists are, the noise/signal (no pun, or irony intended) can hide the quality information. For something as evocative as this GPS/SD issue, I'd like to see at *least* daily updates posted to an official website or blog (not wiki). Even if those updates just say, Still working on this problem, next update in 24 hours.. Bravo so far, fingers crossed for an acceptable fix. Matt On Wed, Jul 16, 2008 at 11:22 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Alejandro - This issue does not look good. Is there someone in Openmoko or FIC aware of it? Aware of it? You must be kidding. Pretty much everybody at Openmoko, including Sean our beloved leader, reads the mailing lists. All mailing lists. Then we have internal mailing lists, and if you could see what's going on there right now, rest assured there are 5-10 people working on tracking down the GPS bug, and other bugs, right now. Software fixes, hardware fixes. Shipped units, units currently in production, future production runs. All require different approaches and all of this is being addressed. The idea that the GPS problems might be related to SD card presence was a fantastic idea, and coming from our community! After the gta02 release dust settles, I will take another look at how we can make our internal communication more public. It's all too easy that good things are going on and people don't know about. Expect to see more in the coming days. Best Regards, Wolfgang On Jul 15, 2008, at 10:30 PM, Alejandro Enrique wrote: This issue does not look good. Is there someone in Openmoko or FIC aware of it? If it is something that has to be fixed in hardware it may have a big impact in the project at this stage. I hope there will be some software workaround for this. 2008/7/15 Jay Vaughan [EMAIL PROTECTED]: On the 1973?! Yup. None of us can confirm this, our 1973 are mostly ok, only the Freerunners make problems. I do not have a Freerunner yet. But for sure, without the SD card in, GPS seems to acquire faster. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Alejandro Enrique ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki editors
On Wed, Jul 16, 2008 at 8:54 AM, ian douglas [EMAIL PROTECTED] wrote: Michael Shiloh wrote: I will help support you in any way I can. Yes, we can absolutely set up a mailing list for you to coordinate amongst yourselves. I will also make myself more immediately available to the wiki editors, so that questions can be answered as rapidly as possible. Hiya Michael, Quick question: what exactly is Brenda's role? http://openmoko.markmail.org/search/?q=brenda#query:brenda%20date%3A200802%20+page:1+mid:cancdihaeug2s7x2+state:results This leads me to believe it's Brenda's full-time job (as in, employment), to be the wiki editor, organize the articles, etc., so we certainly would value her insights and opinions. We certainly aren't trying to muscle in on her territory, but just willing to lend a hand to what is a daunting, gigantic challenge of finding and editing a LOT of information. Secondly, Michael can you coordinate with whoever is in charge of the wiki software to include the plugin I mentioned last night: http://www.mediawiki.org/wiki/Extension:DumpHTML One of my own agenda points as a wiki editor is to get an offline-capable version of the wiki available for download to install on the SD card -- perhaps we could even build it up as an opkg documentation bundle or something. That'd be slick, with opkg update opkg upgrade being able to upgrade the documentation on the phone. Wiki editors, do you have a request for the list name? How about openmoko-wiki-editors? Since openmoko is already in the domain name, perhaps just [EMAIL PROTECTED] would be sufficient? -id Just [EMAIL PROTECTED] wiki-editors sounds like an official title and that may dissuade people from joining. Also, surely this list would not exclude wiki-reviews, wiki-graphic-designers, wiki-proofreaders, etc. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OM's wiki be used offline?
mokopedia brings the whole wikipedia to your openmoko phone even while being offline because all articles will reside on an attached microSD card. http://projects.openmoko.org/projects/mokopedia/ On Tue, Jul 15, 2008 at 8:00 AM, Kurt Snieckus [EMAIL PROTECTED] wrote: GNU wget can recurse and download a site. http://www.editcorp.com/Personal/Lars_Appel/wget/wget_3.html http://blog.theunixgeek.org/?p=18 -Kurt On Mon, Jul 14, 2008 at 5:32 PM, Yaroslav Halchenko site-openmoko.org@ onerussian.com wrote: Hi All, In the sight of upcoming delivery of our 10-pack, we wanted to get ready to do some testing on the spot, ie when we get together and open our boxes, to power then up and try to make sure that all of them work in the 'similar' fashion (GPS, GSM, etc) so if there is a defective unit, we could localize it easily since we will have a few of them and a few of SIM cards to try ;-) But if smth doesn't work, of cause, the best way is to lookup on the wiki and we will not have (I think) internet connection on the spot. I thought if it is possible to gently (smth not like wget -m http://www.openmoko.org) obtain a copy of openmoko.org's mediawiki content. Brief googling lead me to few possible solutions (unfortunately not non-intrusive into openmoko's wiki setup) such as Mediawiki offline (thanks to Google Gears): http://wiki.yobi.be/wiki/Mediawiki_LocalServer But I wonder may be there is simpler/better ones like a dump of DB without account information credentials, etc? Something like what wikipedia offers http://en.wikipedia.org/wiki/Wikipedia:Database_download (which they actually closed and I see the reason with their sizes), but they also seems to have a workaround http://meta.wikimedia.org/wiki/Wikix -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- http://sneaktime.net -- [EMAIL PROTECTED] -- 1.609.297.8828 ___ 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: SanDisk micro SDHC 8GB card under testing
It will depend of the amount and type of activity and size of files. I like the look of nilfs or logfs,but I'm not sure they are available or even mature enough. Flyin_bbb8 wrote: So what's the best filesystem to use on our microSDs? On Sat, Jul 12, 2008 at 12:51 AM, Mikko Rauhala [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: pe, 2008-07-11 kello 15:44 -0600, Joe Pfeiffer kirjoitti: Checking you're right. I could swear I saw early on that the whole reason jffs2 was used on the GTA01 was because SD didn't do that. So anybody know why it was used? Bee-cause the internal flash is not SD but raw flash, on both Neos? -- Mikko Rauhala - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
I found a Sandisk Micro SD 8gb on the pavement today. It was full of *.nds files, Nintendo DS roms I think. Will it work in the FR? ian douglas wrote: Hey all, Got my 8GB SanDisk 8GB micro SDHC card [1] in a few minutes ago, popped it into my GTA02v5 (beta tester model) Freerunner and running a few tests on it. So far, so good. [EMAIL PROTECTED]:~# mount | grep media /dev/mmcblk0p1 on /media/card type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1) [EMAIL PROTECTED]:~# df -h | grep media /dev/mmcblk0p17.6G 32.0k 7.6G 0% /media/card If anything weird comes up in my testing, I'll let everyone know. -id [1] http://www.newegg.com/Product/Product.aspx?Item=N82E16820171320 ___ 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: In the press
Jay Vaughan wrote: This stood out for me The tangled pile of mostly outdated and incomplete documentation at the OpenMoko wiki... Is this an accurate evaluation of the wiki ? If so, what can we do to fix it up, how do we identify old content and schedule it for updating? I think, personally, its time for a 3rd-party site not related to OpenMoko to pick up the slack here. So much stuff happens too quickly for people who /should/ be updating the wiki to feel like its productive to do so .. What I would like to see is something like an mokofanboix.org website come up that has the following: - Daily blog news akin to the good ol' slashdot, of news from the openmoko scene, gleaned from careful inspection of the mailing lists, of IRC, of the codebase, of code delta's, etc. - Public free Repository of all the latest and greatest 'cool apps' found for OpenMoko - Public forum for discussion of the news. This is, of course, sorta what we've got with things like planet.openmoko.org (which I check daily), combined with the Scaredycat repo's and other such things, but .. for newcomers .. I don't think any of this is as easily approachable as it would be if it were all put under a single umbrella that is a bit more of an 'openmoko pop culture' site than what we've got right now .. ; -- Jay Vaughan I agree. Regardless though, an out of date wiki is not helpful. What approaches can we take to fix up the wiki ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
Federico Lorenzi wrote: On Thu, Jul 10, 2008 at 3:56 PM, ian douglas [EMAIL PROTECTED] wrote: So interestingly enough, writes were slower on ext3 than vfat on the 512MB card. Makes sense, ext3 is journaled, and using a journaling FS on flash memory is generally a bad idea. Could you also try ext2? Thanks, Federico ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I had some performance issues using ssd on my laptops a while back. At the time I couldn't find much out about the various merits of different filesystems and block sizes. I recently searched again and found this document : http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf Looking thought charts ( I wish there was a podcast), it looks like a 4kb block size is best, and nilfs performance best as the filesystem. nilfs http://www.nilfs.org/en/ here's an interesting thread on using nilfs on ssd http://www.nilfs.org/pipermail/users/2008-February/000188.html Is nilfs availble for openmoko ? Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
In the press
I found this yesterday, thought it was quite an ok article. http://arstechnica.com/reviews/os/open-moko-software.ars This stood out for me *The tangled pile of mostly outdated and incomplete documentation at the OpenMoko wiki*... Is this an accurate evaluation of the wiki ? If so, what can we do to fix it up, how do we identify old content and schedule it for updating? Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: VMWare Freerunner Flash
Johan Badenhorst wrote: Hi guys, I was just wondering if anyone has flashed their Freerunners using VMWare Player on Windows and if that would even be possible? Alternatively would it be possible to use colinux or a similar tool? I've been developing for Maemo using VMWare successfully because I am stuck without a linux machine at present. The Internet Tablets have a Windows flashing tool though, so I've never had to attempt to flash from a virtual machine. If this isn't an option I'll use a live CD. Thanks for any response and good luck to all the other developers out there getting ready for the arrival of your freerunners e I don't have experience of VMWare with a Freerunner, but in my experience vmware (windows free version) usb devices can be problematic. It's been a while, but I think you need to have the vm in focus when you connect the device, and the device should be connect after the vm boots. Trivial to try, so please let us know what works. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions about our mailinglists
Torfinn Ingolfsen wrote: Hi, On Tue, Jul 8, 2008 at 5:08 AM, Matt Joyce [EMAIL PROTECTED] wrote: Dear Community Would there be any support for prefixing the subject with the list names ? eg [openmoko-community] It's a trivial enough to implement with Mailman (the system being used). No, please don't do that. I repeat: please do not mess with the subject lines! To see why, look at the list archives about a year back. I looked but other than some mild munging of some subjects, I can't see what you're referring to. I personally have been subbed to numerous mailing lists which [do this], and I have not had a bad experience worthy of the anxiety you seem to suggest. Can you elaborate please (not for the sake of debate, I'm just curious how I have missed the pitfalls for so many years)? MJ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
Not really my idea of quite accurate! It's just initialisation data. More accurate will probably be better, but 20km of doesn't sound that bad. It sure is *way* better than not even knowing which hemisphere you're in. Actually it think just knowing which country your in will make a big difference allready. We could consider devising a list of country/location data, assuming we can get country information from the GSM network (or the SIM card perhaps?). Just adding this to the GPS initialisation might allready reduce the time needed to get a fix hugely. AVee I'm not sure what capacity there is to connect via VPNs, but they could make a device appear to be in a different hemisphere. mj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions about our mailinglists
Torfinn Ingolfsen wrote: Hello, On Tue, Jul 8, 2008 at 1:44 PM, matt joyce [EMAIL PROTECTED] wrote: Can you elaborate please (not for the sake of debate, I'm just curious No, I'm not going to restart that discussion. The last time it lasted for more than a month, wasting lots of time for anybody reading this list, and even more for those participating in the discussion. I did check the faq (http://wiki.openmoko.org/wiki/FAQ#Misc) before asking, there was no mention of the problem. Oh well, never mind. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions about our mailinglists
arne anka wrote: No, I'm not going to restart that discussion. so you were speaking about the discussions that may arise from the request not some drawbacks of the markers as such? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Oh I see, I was looking for unpleasant artefacts of subject tagging, not a dichotomising debate. I looked again but searching a mailing list archive for 'subject' is too tedious. mj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions about our mailinglists
Dear Community We want to simplify around key communication points. What do you think of the following: 1) Combine 'openmoko-devel' and 'distro-devel' into one list -- called 'devel'. 2) Remove 'device-owners'. 3) Remove 'hardware'. Any concerns / comments? -Sean I imagine the above questions have been asked in the respective lists, if they are happy to join Community, I for one am happy to read their threads. Would there be any support for prefixing the subject with the list names ? eg [openmoko-community] It's a trivial enough to implement with Mailman (the system being used). Also, should a link to the wiki be included in the list footers? Perhaps it would be useful to new users (which I expect and hope there will be many). Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
