Re: squid problem
G'day, Is the page actually in the cache? Looking at the page doesn't automatically keep a copy of it. Adrian On Tue, Mar 04, 2008, sulochan acharya wrote: Hey Adrian, I have a small problem with squid offline mode. I was hoping that you would point me to right direction. 1. I can not access pages in offline_mode. Here is what i did: on squid.conf i added cachemgr_passwd none offline_toggle then squidclient mgr:offline_toggle---it said this HTTP/1.0 200 OK Server: squid/2.6.STABLE16 Date: Tue, 04 Mar 2008 06:53:39 GMT Content-Type: text/plain Expires: Tue, 04 Mar 2008 06:53:39 GMT Last-Modified: Tue, 04 Mar 2008 06:53:39 GMT X-Cache: MISS from sugaroffice.ole X-Cache-Lookup: MISS from sugaroffice.ole:3128 Via: 1.0 sugaroffice.ole:3128 (squid/2.6.STABLE16) Proxy-Connection: close offline_mode is now ON I closed my internet connection, and tried to access a page that i was viewing earlier but no result So, what am i missing? Is it something to do with routing? or cache-lookup not being available. Thanks in advance. best, Sulochan. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, Mar 4, 2008 at 6:54 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Waqas Toor wrote: | Hello All, | | I am having a problem and unable to find any solution regarding that, | I have written an activity in using GTK and glade, and have sugarized | it according to the hello world tutorial in wiki. but still i dont | know what is going on as the icon of the activity stays in the ring | and then disappears after some time, i have rechecked my code again | and again and cant find any thing that is of Coding error | | | can anybody please see the log i am attaching and tell me is rainbow | stoping it ?? You appear to have discovered a bug in Rainbow, which is dying with an assertion failure. Until Rainbow is fixed, you should do as Walter suggested and disable Rainbow. Ben is right. I think the problem is that your activity dir is world writable, you could try changing that and continue testing your activity inside Rainbow. Compare the permissions of your activity dir and contents with other activities. Can you enter a ticket about this? I don't know if Rainbow should abort the launch in these cases, but certainly should give a more helpful message. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Today's mesh testing.
C. Scott Ananian wrote: How did you get sharing to use unicast? Was this a special patch, or is this actually the default? (My understanding is that sharing is multicast.) telepathy-gabble via a jabber server is always unicast. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: uucp for sneakernet (was Re: Emulating the School...]
008/3/4 Bennett Todd [EMAIL PROTECTED]: 2008-03-03T05:50:31 [EMAIL PROTECTED]: We are studying the Wizzy and all the UUCP related issues. Don't know what Wizzy is, but _very_ glad to hear uucp is being looked at for sneakernet[1]. It's been 10 years since I used http://www.wizzy.org.za/ http://lists.laptop.org/pipermail/server-devel/2008-February/000221.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1741
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1741 Changes in build 1741 from build: 1726 Size delta: 0.13M -bootanim 0.14-0 +bootanim 0.15-0 -telepathy-salut 0.2.2-4.olpc2 +telepathy-salut 0.2.2-5.olpc2 -sugar-presence-service 0.75.2-1.olpc2 +sugar-presence-service 0.75.3-1.olpc2 --- Changes for telepathy-salut 0.2.2-5.olpc2 from 0.2.2-4.olpc2 --- + dev.laptop.org #6310: crash in clique multicast code -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 695
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build695 Changes in build 695 from build: 694 Size delta: -0.13M -ohm 0.1.1-6.9.20080119git.fc7 +ohm 0.1.1-6.10.20080119git.fc7 -sugar-presence-service 0.75.1-1.olpc2 +sugar-presence-service 0.75.2-1.olpc2 --- Changes for ohm 0.1.1-6.10.20080119git.fc7 from 0.1.1-6.9.20080119git.fc7 --- + When coming out of sleep (lid open or power button), tell NetworkManager -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/update.1-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
E-Paati Activity Bundle version 8 released
OLE Nepal has released version 8 of its E-Paati suite of activities. These are the activities that OLE Nepal is preparing for Nepal's Spring pilot of OLPC, starting April 13th, for grades 2 and 6. http://dev.laptop.org/pub/epaati/Epaati-8.xo This a large .xo file at approximately 53 MB. The large size is due to the fact that the .xo bundle collates many individual activities into a single bundle. Please download, test, and let us know what you think. And of course, please modify, translate, improve, etc. The E-Paati suite is licensed under the MIT license. Sulochan Acharya OLE Nepal http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 1741
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1741 Changes in build 1741 from build: 1723 Size delta: -0.13M -avahi-dnsconfd 0.6.21-10.olpc2 +avahi-dnsconfd 0.6.21-11.olpc2 -bootanim 0.14-0 +bootanim 0.15-0 -ohm 0.1.1-6.9.20080119git.fc7 +ohm 0.1.1-6.10.20080119git.fc7 -telepathy-salut 0.2.2-4.olpc2 +telepathy-salut 0.2.2-5.olpc2 -avahi-autoipd 0.6.21-10.olpc2 +avahi-autoipd 0.6.21-11.olpc2 -avahi 0.6.21-10.olpc2 +avahi 0.6.21-11.olpc2 -avahi-glib 0.6.21-10.olpc2 +avahi-glib 0.6.21-11.olpc2 -avahi-tools 0.6.21-10.olpc2 +avahi-tools 0.6.21-11.olpc2 -sugar-presence-service 0.75.2-1.olpc2 +sugar-presence-service 0.75.3-1.olpc2 --- Changes for ohm 0.1.1-6.10.20080119git.fc7 from 0.1.1-6.9.20080119git.fc7 --- + When coming out of sleep (lid open or power button), tell NetworkManager --- Changes for telepathy-salut 0.2.2-5.olpc2 from 0.2.2-4.olpc2 --- + dev.laptop.org #6310: crash in clique multicast code --- Changes for avahi 0.6.21-11.olpc2 from 0.6.21-10.olpc2 --- + add patch to avahi-daemon.conf so that the workstation record is not -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Read ETexts Activity is set up
On Tue, 04 Mar 2008 09:34:20 -0600, James Simmons [EMAIL PROTECTED] wrote: Project name : Read ETexts Activity Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/activities/read Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Read ETexts Activity is set up
Hi, Project name : Read ETexts Activity Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/activities/read We already ship an activity called Read with the XO -- could we call the repository for this one something like etexts to avoid confusion? - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: default jabber server?
Wilson Farrell wrote: If anyone gets ejabberd running correctly using those instructions, please let me (or just the list) know. I posted a while back with a list of issues and received no response. I got busy with other things. This thread brought it all back. I think I've resolved all your issues with my instructions - see my previous mail to devel@ about http://wiki.laptop.org/go/Installing_ejabberd. I believe the setting up shared roster roster is not correct, and I had every intention of updating the wiki as soon as I figure out what was wrong... that never happened. It was subtly incorrect, as a result of a change from using a complete shared roster (@all@) to the @online@ group. I have corrected that page, but I think you'll find [[Installing ejabberd]] easier to follow. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, Mar 04, 2008 at 10:12:35AM +0100, Tomeu Vizoso wrote: On Tue, Mar 4, 2008 at 6:54 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Waqas Toor wrote: | can anybody please see the log i am attaching and tell me is rainbow | stoping it ?? As Tomeu said, Rainbow has detected that your activity's directory, /home/olpc/activities/Qirat.activity, is writable by the activity. Activities are not permitted to modify their own bundles. Consequently, Rainbow scuttled the launch. You appear to have discovered a bug in Rainbow, which is dying with an assertion failure. Until Rainbow is fixed, you should do as Walter suggested and disable Rainbow. Is there some reason why activities need to write to their (or to other activities') bundle directories? Can you enter a ticket about this? I don't know if Rainbow should abort the launch in these cases, but certainly should give a more helpful message. Tomeu: what do you suggest Rainbow should do in response to this kind of assertion failure? Should we really try to print a more readable explanation of what failed, given the degree to which such explanations would bloat the code-base? Also, if so, does this message need to be localized? I'm happy to try to improve the legibility of both the failures and the code itself; however, the fact that you were able to correctly diagnose the error (which has never been reported before) and to propose a fix (change the permissions on the bundle dir) suggests to me that I got at least one thing right... :) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, 4 Mar 2008, Michael Stone wrote: As Tomeu said, Rainbow has detected that your activity's directory, /home/olpc/activities/Qirat.activity, is writable by the activity. Activities are not permitted to modify their own bundles. Consequently, Rainbow scuttled the launch. That's good of it. Tomeu: what do you suggest Rainbow should do in response to this kind of assertion failure? Should we really try to print a more readable explanation of what failed, given the degree to which such explanations would bloat the code-base? Also, if so, does this message need to be localized? I would suggest printing a URL to a page on wiki.laptop.org that has more information and/or an error code with a link to look up the error code. (I prefer the former, but the latter could save a few bytes (that I think are probably not worth saving) by storing only one URL for looking up the problems, plus the error code strings/numbers, combining them at error print time.) -- Asheesh. -- If you do something right once, someone will ask you to do it again. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, 2008-03-04 at 17:37 -0500, Michael Stone wrote: On Tue, Mar 04, 2008 at 10:12:35AM +0100, Tomeu Vizoso wrote: On Tue, Mar 4, 2008 at 6:54 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Waqas Toor wrote: | can anybody please see the log i am attaching and tell me is rainbow | stoping it ?? As Tomeu said, Rainbow has detected that your activity's directory, /home/olpc/activities/Qirat.activity, is writable by the activity. Activities are not permitted to modify their own bundles. Consequently, Rainbow scuttled the launch. You appear to have discovered a bug in Rainbow, which is dying with an assertion failure. Until Rainbow is fixed, you should do as Walter suggested and disable Rainbow. Is there some reason why activities need to write to their (or to other activities') bundle directories? I would argue that activities should not be allowed to write to their bundle directories, and that Rainbow is enforcing the correct requirement. I am calling this a bug because Rainbow should achieve this without an assertion failure. According to my software engineering professors, a program should always handle any input data without an assertion failure. Assertions are for catching bugs in internal invariants. Therefore, any time an assertion failure is reached, it represents a bug. If Rainbow wants to disallow this, it should raise a specific exception. Can you enter a ticket about this? I don't know if Rainbow should abort the launch in these cases, but certainly should give a more helpful message. #6640. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, Mar 04, 2008 at 06:16:34PM -0500, Benjamin M. Schwartz wrote: According to my software engineering professors, a program should always handle any input data without an assertion failure. Assertions are for catching bugs in internal invariants. Therefore, any time an assertion failure is reached, it represents a bug. My central error-handling goal has been to compactly express my assumptions in a form that will prevent them from being violated in ignorance. Should I have different goals? If Rainbow wants to disallow this, it should raise a specific exception. Given your knowledge of Rainbow's clients, both human and software, what would be gained by spending the time, documentation, and code required to create and raise a specific exception for each unique way to violate my assumptions? Can you enter a ticket about this? I don't know if Rainbow should abort the launch in these cases, but certainly should give a more helpful message. Again, who is the audience for the message? It was clearly helpful for Tomeu and me; it was clearly not as helpful for Waqas. Waqas - what could Rainbow have done better for you? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | On Tue, Mar 04, 2008 at 06:16:34PM -0500, Benjamin M. Schwartz wrote: | According to my software engineering professors, a program should | always handle any input data without an assertion failure. Assertions | are for catching bugs in internal invariants. Therefore, any time an | assertion failure is reached, it represents a bug. | | My central error-handling goal has been to compactly express my | assumptions in a form that will prevent them from being violated in | ignorance. Should I have different goals? 1. I find Rainbow very impressive, and I am sure you are well aware of the various arguments made regarding error handling. In my view, restricting assertions to internal invariants provides an easy way of distinguishing problems in Rainbow from problems in Activities and other parts of the system. 2. Among your goals, you might consider maximizing the ability of novice programmers to figure out what they've done wrong. OLPC's goals include bringing in many developers who have no experience, so it is important the system be friendly to, say, Python programs written by people who don't know Python. The wiki page on translation even goes so far as to recommend using gettext for error strings, so that users and administrators may debug the system without knowing English. 3. Did this assertion failure result in the termination of the Rainbow daemon? It certainly seems like it could have, though your response suggests otherwise. Most programs simply exit after an assertion failure, because the failure indicates that the program's internal state is no longer sensible. Raising exceptions for input errors has the distinct advantage of allowing one to catch exceptions thrown further down the call stack, instead of exiting. Note that when I say specific exceptions, it would be perfectly reasonable to wrap up all errors due to permissions in a PermissionsException, etc. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzfXXUJT6e6HFtqQRAhSwAJ4lobW9HT6OWtonFQjQI93ppGlGwACfTgBv AaXnBTOaXz1QrfGlc80xupU= =YfUX -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: default jabber server?
Morgan, Did you follow the thread last week where using the instructions you put into the Wiki didn't work ? Using the old instructions did. At this point, I've set up over a half dozen ejabberd servers using the old directions, and collaboration works. wad On Mar 4, 2008, at 1:20 PM, Morgan Collett wrote: Wilson Farrell wrote: If anyone gets ejabberd running correctly using those instructions, please let me (or just the list) know. I posted a while back with a list of issues and received no response. I got busy with other things. This thread brought it all back. I think I've resolved all your issues with my instructions - see my previous mail to devel@ about http://wiki.laptop.org/go/ Installing_ejabberd. I believe the setting up shared roster roster is not correct, and I had every intention of updating the wiki as soon as I figure out what was wrong... that never happened. It was subtly incorrect, as a result of a change from using a complete shared roster (@all@) to the @online@ group. I have corrected that page, but I think you'll find [[Installing ejabberd]] easier to follow. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
On Tue, Mar 04, 2008 at 08:22:31PM -0500, Benjamin M. Schwartz wrote: Michael Stone wrote: | My central error-handling goal has been to compactly express my | assumptions in a form that will prevent them from being violated in | ignorance. Should I have different goals? 1. I find Rainbow very impressive, and I am sure you are well aware of the various arguments made regarding error handling. Thank you. While it's true that I'm aware of some arguments regarding error handling, I'm always interested in improving. It seems like one of the most regularly failed challenges in the craft of programming. In my view, restricting assertions to internal invariants provides an easy way of distinguishing problems in Rainbow from problems in Activities and other parts of the system. True, but the convention that I have established of separating error messages into contract-violations and 'everything else', recorded in per-activity logs and in a daemon-wide log (/var/log/rainbow) would seem to accomplish similar goals. 2. Among your goals, you might consider maximizing the ability of novice programmers to figure out what they've done wrong. It's not my primary goal, but I'll agree that it's worth considering. The wiki page on translation even goes so far as to recommend using gettext for error strings, so that users and administrators may debug the system without knowing English. I'm still not convinced. Wouldn't we be better served by translating the source code itself, or an overview of the source code like my 'Taste the Rainbow' pages? Consider: in my experience, debugging consists of searching the diff between one's mental model and reality from which it follows that the material which should be translated is the material which provides the clearest, most accurate mental model of the problem. Also consider: had there been an actual bug in Rainbow, which would have been more useful to Waqas in diagnosing and fixing the problem: translated error messages or better written or documented source code? Put another way, doesn't this kind of error message uselessly duplicate information that is best recorded in the failing assertion itself (and in the name of the function containing it, in this case, check_cwd(... [cwd=]/home/olpc/Activities/Qirat.activity) assert ck.negative(W_OK, 0) ? 3. Did this assertion failure result in the termination of the Rainbow daemon? The present implementation calls clone() before executing any activity-launching code. Termination of the child by failure to handle the AssertionError is a design goal. Raising exceptions for input errors has the distinct advantage of allowing one to catch exceptions thrown further down the call stack, instead of exiting. Note that when I say specific exceptions, it would be perfectly reasonable to wrap up all errors due to permissions in a PermissionsException, etc. First, what can I reasonably expect to accomplish by catching such an exception? Second, given that the exception is being raised in a child process that may have been compromised by malicious data, I'm not terribly interested in informing the main daemon to the particulars of the failure; the log file is quite sufficient for my purposes. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: default jabber server?
Following the new and the old yields the same result for me, but the new page required less trial and error. The new page was much easier to follow. Thanks! In the old instructions the setup of the shared roster were not correct (subtly incorrect I suppose, but if you follow the directions literally, I can assure you they were not correct). They were corrected on the ejabberd configuration page recently. When you say Collaboration works, do you mean that sharing an activity will result in that shared activity appearing on the neighborhood view of other XO's connected to your ejabberd server. I have to explicitly invite a user to an activity for it to appear on that remote XO's view. That appears to be the only issue I am having. Collaboration seems to be fine, once I am invited to and join a shared activity. Finding the shared activities in the first place seems to be the problem. You should know that I am running 653 on two OLPC (one actual G1G1 and the other in a VM) connected to an ejabberd server (on a separate VM). I understand that my XO software is a bit dated. I was going to wait until update.1 was out to start troubleshooting this again, but there were a couple of posts that got me all stirred up about it. I know everyone is busy with testing. As far as I am concerned this is a low priority issue, but I do continue to watch the list for any nugget that can help. Thanks! Wilson John Watlington wrote: Morgan, Did you follow the thread last week where using the instructions you put into the Wiki didn't work ? Using the old instructions did. At this point, I've set up over a half dozen ejabberd servers using the old directions, and collaboration works. wad On Mar 4, 2008, at 1:20 PM, Morgan Collett wrote: Wilson Farrell wrote: If anyone gets ejabberd running correctly using those instructions, please let me (or just the list) know. I posted a while back with a list of issues and received no response. I got busy with other things. This thread brought it all back. I think I've resolved all your issues with my instructions - see my previous mail to devel@ about http://wiki.laptop.org/go/Installing_ejabberd. I believe the setting up shared roster roster is not correct, and I had every intention of updating the wiki as soon as I figure out what was wrong... that never happened. It was subtly incorrect, as a result of a change from using a complete shared roster (@all@) to the @online@ group. I have corrected that page, but I think you'll find [[Installing ejabberd]] easier to follow. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: uucp for sneakernet (was Re: Emulating the School...]
uucp ... the first place I'd turn for sneaker-netting posix-ish systems together. http://en.wikipedia.org/wiki/UUCP Yep. UUCP is great if there's a phone line that can dial overnight cheaply, but no Internet. I released the first free implementation of uucp (gnuucp), which was later succeeded by my friend Ian Taylor's Taylor uucp, which I believe is still the best free version. Ian [EMAIL PROTECTED] may still even maintain it (last release: 1.07 in 2003). See: http://www.airs.com/ian/software.html There was also an MSDOS implementation of uuslave (the predecessor of gnuucp), maintained by Tim Pozar [EMAIL PROTECTED], which was widely used to gateway Fidonet nodes to Usenet/UUCP nodes. That was the first project I worked on to bring thousands of 14-year-olds into the global network. See: http://www.lns.com/papers/ufgate/ If a remote school has a dialup phone connection that can run TCP/IP over a modem, that's probably better than running uucp over it, even if you can only run it at night due to telco charges. But uucp has a lot of scheduling and queueing support that more modern TCP/IP systems have forgotten about. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Need Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | On Tue, Mar 04, 2008 at 08:22:31PM -0500, Benjamin M. Schwartz wrote: | Michael Stone wrote: | | My central error-handling goal has been to compactly express my | | assumptions in a form that will prevent them from being violated in | | ignorance. Should I have different goals? | | 1. I find Rainbow very impressive, and I am sure you are well aware of the | various arguments made regarding error handling. | | Thank you. While it's true that I'm aware of some arguments regarding error | handling, I'm always interested in improving. It seems like one of the | most regularly failed challenges in the craft of programming. | | In my view, restricting assertions to internal invariants provides an | easy way of distinguishing problems in Rainbow from problems in | Activities and other parts of the system. | | True, but the convention that I have established of separating error | messages into contract-violations and 'everything else', recorded in | per-activity logs and in a daemon-wide log (/var/log/rainbow) would seem | to accomplish similar goals. I have not read the relevant Rainbow source, so I cannot comment very intelligently on this. However, if Rainbow wishes to log a contract violation, it should insert the phrase contract violation into the logfile. Otherwise, how is a person reading the log to know this? | 2. Among your goals, you might consider maximizing the ability of novice | programmers to figure out what they've done wrong. | | It's not my primary goal, but I'll agree that it's worth considering. | | The wiki page on translation even goes so far as to | recommend using gettext for error strings, so that users and | administrators may debug the system without knowing English. I used the phrase debug the system. That was a poor choice. I should say recognize bugs in the system, and additionally distinguish between bugs in the system and bugs in the activities they're developing. | | I'm still not convinced. Wouldn't we be better served by translating the | source code itself, or an overview of the source code like my 'Taste the | Rainbow' pages? | | Consider: in my experience, debugging consists of searching the diff | between one's mental model and reality from which it follows that the | material which should be translated is the material which provides the | clearest, most accurate mental model of the problem. Your experience is extremely unusual and non-representative. You are an expert computer scientist who frequently reads source code written by others. You are familiar with the OLPC operating system details, including D-Bus and the Bitfrost requirements, perhaps moreso than anyone else in the world. The people who will be reading these logfiles will be developers who are trying to debug their activities. The activity may have crashed because it attempted to violate a Bitfrost rule and was killed by Rainbow. These developers (ideally mostly children) will likely be building their activities by making small modifications to existing activities. That means most won't even understand their own code. How could you possibly expect them to understand yours? | Also consider: had there been an actual bug in Rainbow, which would have | been more useful to Waqas in diagnosing and fixing the problem: | translated error messages or better written or documented source code? Not fixing. It is absurd to imagine that any appreciable number of users will be able fix Rainbow bugs. Rather, when Rainbow experiences an internal error, it should be extremely obvious that the problem is with Rainbow. For example, an excellent type of behavior would be for Rainbow to print, in the logfile: RAINBOW BUG: Rainbow has encountered an internal error. This indicates a bug in Rainbow. The error code is 752. This line would be sufficient for activity developers to understand that the problem is not simply in their code. It also makes it possible for users to participate usefully in the development process, by reporting the bug in an unambiguous way. Error codes are also important because they allow users to identify problems even when e-mailing logfiles is impossible due to software bugs or lack of connectivity. This error line is also nice because it only needs to be translated once, with the error code number substituted programmatically. This output could be improved further by adding an additional sentence, such as: This error code indicates that Rainbow's directory permissions have reached an inconsistent state. This line, like a BSOD, serves mainly to make users feel like the system's designers want them to know what's going on in case of a failure. However, the implementation overhead is undeniably high, especially given the need for many translations. On the plus side, these strings also serve as documentation when reading the source code. | | Put another way, doesn't this kind of error message uselessly duplicate
Re: New update.1 build 696
Many pieces dropped from this build, maybe because of http://dev.laptop.org/ticket/6598 Could you explain more rationale behind these change? And what is the supported way to obtain and install those missing from base-build? Will olpc-update work after this change? /Korakurider On Wed, Mar 5, 2008 at 12:46 PM, Build Announcer v2 [EMAIL PROTECTED] wrote: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build696 Changes in build 696 from build: 695 Size delta: -14.95M -bootanim 0.13-0 +bootanim 0.15-0 -sugar-presence-service 0.75.2-1.olpc2 +sugar-presence-service 0.75.1-1.olpc2 -TamTamMini 44 -Etoys 78 -TurtleArt 7 -Pippy 18 -Calculate 17 -Memorize 25 -Measure 17 -AcousticMeasure 12 -TamTamJam 46 -TamTamEdit 45 -TamTamSynthLab 46 -Terminal 9 -Log 6 -Analyze 5 -NewsReader 24 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/update.1-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 697
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build697 Changes in build 697 from build: 696 Size delta: 0.00M -kernel 2.6.22-20080211.1.olpc.9f4e619336a08dc +kernel 2.6.22-20080304.1.olpc.914fce4d9a8baf3 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/update.1-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 696
On Tue, Mar 4, 2008 at 10:46 PM, Build Announcer v2 [EMAIL PROTECTED] wrote: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build696 Changes in build 696 from build: 695 -sugar-presence-service 0.75.2-1.olpc2 +sugar-presence-service 0.75.1-1.olpc2 Don't we need the school-server-detection bits in s-p-s 0.75.2? (trac #6299). The suggestion in the trac bug is that we need to include the newer Pippy, not revert s-p-s. Unless the sugar developers plan to fix trac #6299 in some other way? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: uucp for sneakernet (was Re: Emulating the School...]
On Tue, 4 Mar 2008, John Gilmore wrote: uucp ... the first place I'd turn for sneaker-netting posix-ish systems together. http://en.wikipedia.org/wiki/UUCP Yep. UUCP is great if there's a phone line that can dial overnight cheaply, but no Internet. I released the first free implementation of uucp (gnuucp), which was later succeeded by my friend Ian Taylor's Taylor uucp, which I believe is still the best free version. Ian [EMAIL PROTECTED] may still even maintain it (last release: 1.07 in 2003). See: http://www.airs.com/ian/software.html There was also an MSDOS implementation of uuslave (the predecessor of gnuucp), maintained by Tim Pozar [EMAIL PROTECTED], which was widely used to gateway Fidonet nodes to Usenet/UUCP nodes. That was the first project I worked on to bring thousands of 14-year-olds into the global network. See: http://www.lns.com/papers/ufgate/ If a remote school has a dialup phone connection that can run TCP/IP over a modem, that's probably better than running uucp over it, even if you can only run it at night due to telco charges. But uucp has a lot of scheduling and queueing support that more modern TCP/IP systems have forgotten about. I've used UUCP over TCP/IP as a mail path for systems that only had intermittent network connectivity and it worked very well. if the system can detect when it does have connectivity and connect up to a server every few min while it retains it, it will do a good job of getting the messages through. you don't need to drop down to dialup to make it work, and using uucp avoids reinventing the wheel, intermittent connectivity is what it was designed for, and it doesn't really matter if that connectivity is serial or TCP/IP. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Issue of Signing Custom Builds
Hey guys, I know that you guys are super crushed w/ Peru's deployment. We really need cryptographically signed custom XO images for Nepal. As I have written to the developers list, we will need different images for grades 2 and 6. Also, we need to load in the Flash Player 9 plugin so we can use the awesome science curriculum developed by E-Shiksha in India www.eshikshaindia.in . Gnash doesn't consistently support the E-Shiksha content Can you guys tell me when it might be possible for us to cryptographically sign our own images so we don't have to leave the XO's unlocked? thanks, Bryan Kathmandu On Mon, 2008-03-03 at 15:42 -0500, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Gilmore wrote: | I recommend that once you have developer keys, you leave the machines | unlocked. You are going to be running a lot of unsigned builds in the | future -- you're customizing your builds. Eventually, there must be a way for countries (and even trials) to get signed custom builds. Either they get their own signing keys, or OLPC offers to sign a nepal.1 branch of tweaked releases. I understand why this infrastructure has not yet been built, but it will be needed in order for Bitfrost to be used at all. - --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 696
C. Scott Ananian wrote: On Tue, Mar 4, 2008 at 10:46 PM, Build Announcer v2 [EMAIL PROTECTED] wrote: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build696 Changes in build 696 from build: 695 -sugar-presence-service 0.75.2-1.olpc2 +sugar-presence-service 0.75.1-1.olpc2 Don't we need the school-server-detection bits in s-p-s 0.75.2? (trac #6299). The suggestion in the trac bug is that we need to include the newer Pippy, not revert s-p-s. Unless the sugar developers plan to fix trac #6299 in some other way? Last I heard this wasn't actually tested yet with a real schoolserver, and Daf and Guillaume were going to change the patch in some way, so from my perspective it's not ready for Update.1. Dennis said it was only tagged into build 695 for the tests last week - so it can still be tested as-is with that build. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 696
Korakurider wrote: Many pieces dropped from this build, maybe because of http://dev.laptop.org/ticket/6598 Could you explain more rationale behind these change? I see more rationale in that ticket now. In particular, it's easy to add activities through Browse (see below) - and activities added this way can be uninstalled and upgraded - but not possible to remove or upgrade activities that are preinstalled in /usr/share/activities. And what is the supported way to obtain and install those missing from base-build? Go to http://wiki.laptop.org/go/Activities in Browse and click on the Download .xo link for each. (Well, that's my understanding of this issue...) Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: default jabber server?
John Watlington wrote: Morgan, Did you follow the thread last week where using the instructions you put into the Wiki didn't work ? Using the old instructions did. At this point, I've set up over a half dozen ejabberd servers using the old directions, and collaboration works. John, I saw that thread, and the page I just mentioned - http://wiki.laptop.org/go/Installing_ejabberd - is a completely new rewrite that I posted on the wiki yesterday, based on a walkthrough for Ubuntu that I posted on my blog[0] last Thursday. I've had at least one report of success using the instructions I blogged (and it worked for me). [0] http://morgancollett.wordpress.com/2008/02/27/olpc-community-jabber-servers-ejabberd-200-from-source/ I'm not sure what you mean by old instructions, but all that was on the wiki as of last week was http://wiki.laptop.org/go/Ejabberd_Configuration (originally by Rob McQueen but edited by various people), and I agree that the shared roster section had errors - I think due to edits by various people that deviated from the original but weren't fully tested. I'll check this page and rectify any remaining errors I can identify. I have seen that you can create shared rosters from the command line using mod_ctlextra, so my next step is to test that and amend http://wiki.laptop.org/go/Installing_ejabberd (the walkthrough) to use that method, and http://wiki.laptop.org/go/Ejabberd_Configuration (the comprehensive developer page) to mention it as an alternative. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: uucp for sneakernet (was Re: Emulating the School...]
On Tue, Mar 04, 2008, [EMAIL PROTECTED] wrote: the good news is that you can simulate things by useing UDP broadcast packets as your transport layer. Well yes, I did usenet/proxy object stuff over UDP. don't get fixated on the idea of using satellites, as a means for publishing updates a high-powered AM or SSB station can blanket a large area, and the efficiancy gained by only transmitting things a couple times (including error correction to deal with missed packets) instead of once to each destination can counter the drawback of a low bit rate. Terrestrial RF would certainly be interesting to trial, but I don't have any equipment here to toy around with and I don't have a radio licence to roll my own. Still, I'd be interested in helping out if anyone is interested. Adrian ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: uucp for sneakernet (was Re: Emulating the School...]
On Tue, 4 Mar 2008, Adrian Chadd wrote: On Tue, Mar 04, 2008, [EMAIL PROTECTED] wrote: I've used UUCP over TCP/IP as a mail path for systems that only had intermittent network connectivity and it worked very well. if the system can detect when it does have connectivity and connect up to a server every few min while it retains it, it will do a good job of getting the messages through. you don't need to drop down to dialup to make it work, and using uucp avoids reinventing the wheel, intermittent connectivity is what it was designed for, and it doesn't really matter if that connectivity is serial or TCP/IP. Did anyone ever publicly extend UUCP to handle multicast messages over broadcast media, like satellite? I did something similar years ago for usenet (as did a lot of other folk) and I'm sure being able to broadcast objects across satellite would be very very useful for the project. I've got plenty of IP/services over Satellite experience here, so I'm happy to help however i can. Its just been a while since I had access to the end node hardware, and stuff has changed quite a bit in the 10 years since I touched it. :) the good news is that you can simulate things by useing UDP broadcast packets as your transport layer. don't get fixated on the idea of using satellites, as a means for publishing updates a high-powered AM or SSB station can blanket a large area, and the efficiancy gained by only transmitting things a couple times (including error correction to deal with missed packets) instead of once to each destination can counter the drawback of a low bit rate. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
