Stupid Question
Hi - I am a developer since 08/07 doing Joyrides etc. but I seem to have lost my activation lease somewhere along the way. I still have my developer key in /security/ but no lease in /ofw/mfg-data/ How to restore? cheat sheet directional keys don't seem to work help. Any hints? Build: joyride 1525 Firmware: Q2D07 -- Regards, Steve Steven C. Fullerton email: [EMAIL PROTECTED] cell/voice mail: 619.339.9116 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: root password
Hi - I don't to varciperate, however --- think about toys. A child uses a toy to discover things about his/her universe at a certain point in time. That is the concept behind OLPC. In constructionist philosophy, a child is given the tools to construct and more importantly share constructed music videos (e.g. tam tam) rather then to listen to them. On Jan 10, 2008 7:44 PM, Ivan Krstić [EMAIL PROTECTED] wrote: On Jan 10, 2008, at 10:19 PM, Carl-Daniel Hailfinger wrote: Besides the nasty wording of your criticism of Albert's opinion, it is quite interesting that you think emphasizing the toy factor displays a stunning level of ignorance and failure of comprehension. In context, Albert uses the word 'toy' as invective. I read his message to say, approximately, that any real use of the machines will be restricted to those kids that the machines turn into bearded UNIX hackers; to all other kids, they'll be nothing more than a video game platform. That position is irreconcilable with the project's stated purpose or the philosophy behind it. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Steve Steven C. Fullerton email: [EMAIL PROTECTED] cell/voice mail: 619.339.9116 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: slightly long and detailed proposal for documentation-translation workflow
Good points. The OLPC is designed around collaboration. The model really works well where every child in a class has his/her own laptop, uses it in and out of school, and lives in close enough proximity to other class members to make the Mesh work. In class one kid discovers how to do something and teaches the other kids (and teachers as well). In an address at Harvard Law, Negroponte said something like: People ask me who is going to teach the teachers to teach the children how to use the XOs --- and I wonder what planet are they on? ... A child who gets one through G1G1 in isolation will not be able to fully benefit from collaboration and thus, along with parent/tutor, would definately benefit from user documentation in lieu of help from others in class. Likewise, the Carlos Slims approach of putting them in Mexican libraries. If G1G1 goes big-time in November, you can sure bet that there will be OLPC for Dummies books, etc. by Christmas. On 10/15/07, Todd Kelsey [EMAIL PROTECTED] wrote: I am amazed and inspired by all the wonderful projects and activities that have arisen from the laptop project -- and though I was skeptical at first, I have also come to appreciate the constructivist approach to education; I didn't get it until I came to appreciate the notion of allowing children to come to aha moments on their own. The fact that children do fine without manuals at the present level of interaction is a testament to the design of the computer and the philosophy behind it. As generation xo grows older, I think they will want to get deeper into the systems, and as they do, I think they will want more information, and I'd like to help make that freely available. I think a user manual or documentation will be more helpful for adult learners who will end up participating in the laptop community, and who would find it helpful to have something to refer to. Perhaps users could learn many things simply by exploring, and yet they might appreciate having something to turn to. Other people may not have personal possession of a laptop, but would be interested in learning how they could support the project. Some people who order the laptops through www.xogiving.org will get frustrated with the laptop if they have no resources to turn to, and I'd like to help them have fun. I think the idea of encouraging children to help each other learn is wonderful; I also appreciate the principle of inclusiveness, and I think that one way to be inclusive is to address various learning styles. On 10/15/07, Steve Fullerton [EMAIL PROTECTED] wrote: Hi Ed and all, I fully appreciate the detail. However, IMHO I think that there is some re-thinking required re: the traditional user documentation. The core of the OLPC (literally one laptop per child; the model does not work as well if there is not possession of a laptop for each child) is that of collaboration. One child learning something and then teaching his/her classmates. OLPC machines are not meant to be used in isolation. You could actually make a credible argument that user manuals are bad for the project. The highly intuitive design of Sugar and the experience of the pilots bears this out. The children seem to do just great without manuals, discovery is enhanced, and many of the constructionist ideals are realized. What do you think? On 10/15/07, Ed Trager [EMAIL PROTECTED] wrote: Hi, Michael, Just a few comments for consideration by everyone: ... Doc writing conventions: Some linguistic research has been done on simplified English as a subset of English to use for low-level learners, and I think that it might be a good place to look for ways to simplify the source_docs. But just thinking intuitively, I have cooked up the following suggestions in order to generate discussion: * Pronouns. o Use the first-person singular pronoun I to represent the author of the docs, o the second-person singular pronoun you to represent the reader of the docs, and o the first-person plural pronoun we to represent the OLPC project. o Examples. We have designed a screen that switches to black-and-white to conserve energy. I will explain how to switch your screen to black-and-white. First, you press the X button on your keyboard Because we want the docs to be easily translated and easily understood, the tone should be personal, using I for the voice of the writer. This will be easier for amateur translators to translate and easier for younger readers to understand. This will also help the writer avoid the passive construction, which is very difficult for some non-native English speakers to understand. I agree completely that the English passive construction should be avoided at all times. I mostly agree with your suggestion
Re: slightly long and detailed proposal for documentation-translation workflow
Hi Ed and all, I fully appreciate the detail. However, IMHO I think that there is some re-thinking required re: the traditional user documentation. The core of the OLPC (literally one laptop per child; the model does not work as well if there is not possession of a laptop for each child) is that of collaboration. One child learning something and then teaching his/her classmates. OLPC machines are not meant to be used in isolation. You could actually make a credible argument that user manuals are bad for the project. The highly intuitive design of Sugar and the experience of the pilots bears this out. The children seem to do just great without manuals, discovery is enhanced, and many of the constructionist ideals are realized. What do you think? On 10/15/07, Ed Trager [EMAIL PROTECTED] wrote: Hi, Michael, Just a few comments for consideration by everyone: ... Doc writing conventions: Some linguistic research has been done on simplified English as a subset of English to use for low-level learners, and I think that it might be a good place to look for ways to simplify the source_docs. But just thinking intuitively, I have cooked up the following suggestions in order to generate discussion: * Pronouns. o Use the first-person singular pronoun I to represent the author of the docs, o the second-person singular pronoun you to represent the reader of the docs, and o the first-person plural pronoun we to represent the OLPC project. o Examples. We have designed a screen that switches to black-and-white to conserve energy. I will explain how to switch your screen to black-and-white. First, you press the X button on your keyboard Because we want the docs to be easily translated and easily understood, the tone should be personal, using I for the voice of the writer. This will be easier for amateur translators to translate and easier for younger readers to understand. This will also help the writer avoid the passive construction, which is very difficult for some non-native English speakers to understand. I agree completely that the English passive construction should be avoided at all times. I mostly agree with your suggestion on use of pronouns. Use of I and we are fine. REGARDING THE PRONOUN YOU IN ENGLISH: -- However, as a native English speaker, I find the use of the pronoun you in the imperative mood often quite jarring. Imperative sentences in which the you is absent are understood by native speakers of English to convey a softer, less imperative tone. Such sentences are considered more polite. Compare: (A) First you press the X button on the keyboard. ... versus: (B) First, press the X button on the keyboard. One or two instances of you in imperatives or directions in spoken or written English may not seem too bad, but after a series of them, it becomes irritating. So while I have no objection to simple English which will be easily understood by younger learners of the language, we must also be sure that we do not proscribe an incorrect idea regarding the usage of the pronoun you in imperative sentences in English. In short, it is *not* OK to use you repeatedly in a series of imperatives or directions (such as instructions for using a laptop). The absence of the pronoun you is preferred when giving directions in English. REGARDING POSSESSIVE PRONOUNS: --- Look again at the sentances Michael used for his example: I will explain how to switch your screen to black-and-white. First, you press the X button on your keyboard English speakers make frequent use of possessive pronouns, as is the case here with : your screen , your keyboard . But in many other languages (perhaps most other languages?) we would not use possessive pronouns here at all. All of these English yours, if translated quite directly into foreign languages, results in very annoying and unnatural sounding texts in my experience. So I would advise we try to fix the English from the start by avoiding unecessary invocations of possessive pronouns, especially your: I will explain how to switch the screen to black-and-white. First, press the X button on the keyboard I basically agree with the rest of Michael's suggestions, so that's all the comments I have. -- Ed Trager ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Steve Steven C. Fullerton email: [EMAIL PROTECTED] cell/voice mail: 619.339.9116 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pippy and Calculate - Evolution Solution
Hi All, I am a lurker, but this is an interesting discussion. I am a developer in health applications working with current dev release on a B4. Calculate is impressive; Pippy is impressive. They each serve a purpose which I think fits into an OPLC evolutionist philosophy. First, there are US toys that are remarkably similar to the OLPC in appearance that comprise a simple 4x4 calculator aimed at the under 5 year old crowd. Large keys that do arithmetic. Guido in his wisdom, incorporated and uses in his tutorial the calculator attributes of python to convey --- not arithmetic --- but the meaning of interpretive to a neophyte programmer. I think both activities have a place, and further, should/could be seamlessly integrated so that a child in the Ivory Coast who learns arithmetic using Calculate can discover Pippy and say: Zoot alors! Je peux faire la même chose dans Pippy ! or something like that. Very constructionist. A intellectual bridge to understanding and learning python prior to being able to comprehend a Fibonacci series (although we want kids to get there as quickly as possible.) As a very simple example of seamlessness, I would change the enter key in the Calculate activity to mimic exactly in size/shape the enter key on the OLPC keyboard -- e.g. square with check box symbol and maybe do the same in Pippy in place of the print key that Yoshiki suggests? I don't think we can escape the fact that the OLPC activity suite will ultimately have to be configurable at the national, school, teacher, and pupil levels. I think there is a reason and purpose for both Calculate and Pippy. Some p.s. thoughts --- Many Applications/Activity developers seem to have a natural inclination to add complexity as the activity evolves --- witness MS Windows. In the OLPC I would suggest that we strive to add simplicity. Will millions of children who grew up using Sugar want to transition to MS Windows when they come of age? I think/hope not. /Steve On 9/5/07, Yoshiki Ohshima [EMAIL PROTECTED] wrote: Hi, Chris, (I'm the Pippy author.) (We didn't have much time to discuss with you while I was in Cambridge two weeks ago...) Imagine if Pippy has a button called Print!, which would be located right next to the Run! button. And, if Print! prints out the results of running the program into the bottom pane, that is pretty much all we need. (For the record, the workspace in Etoys has been there from day one for this purpose.) This is a useful idea, thanks. At the moment, Pippy doesn't keep any variable/program state inbetween Run!s (each run is a new Python interpreter), so there is no way to do Ans*2-style calculations. It sounds like you want Print! to keep a single interpreter that reinterprets the source pane at each click. I didn't think about that aspect, but keeping state will be useful. The first version of Pippy used a single Python interpreter that executed the program source code in this way, without losing state, but that makes it possible to write programs that will not run on a fresh interpreter later (as they refer to state that was generated as a result of code that no longer exists, or a previous run of the code), so I decided against keeping that. Yeh, that can happen in a typical workspace programming. But in Pippy's setting, it would not be much of a problem. Keep button can store the state altogether into a journal entry. Oh! We could have an example in Pippy that, when run, gives you a Python interactive shell. That should work well; it gives you the mode you want (without requiring an extra button), and is useful in any case. I'll do that. I don't think Python's evaluations are useful as a calculator to a child, though. You would have to explain this: 2+2 4 3/4 0 I would like to add a simple graphics screen to Pippy, but I don't intend it to get many more features past that -- I'd like to keep it at a simple introduction to input/output programming. Yeah, I was aware of the division (/) problem (when I see the last digit in Calculate falls off to the next line. It would be nice if you can override the division operator... We have a real problem of shortage of man-power, so replacing smaller activities that take more time to maintain and document with more powerful ones is probably a good thing. Just a note that Reinier Heeres is a volunteer, so isn't pulling OLPC man-power away from any other projects. Well, a volunteer can certainly contribute one of OLPC projects, right? I now see that the timeframe and practical matters will probably prevent us going to the nice merging point between these different projects. However, I still contend that similarity is close enough. So, for example Pippy doesn't have to be confined this is a Python thing mind, but take advantage of similarity. -- Yoshiki
Autoreinstallation problem --- current developer build
Autoreinstallation problem - 9/1/07 machine: B4 firmware: q2c25 and q2c26 build: 564 Hi all --- 'followed all the autoreinstallation instructions, plenty of USB flash properly formatted as FAT; no partitions. Several successful autoreinstallations in past 4 weeks. Firmware reinstalls fine, os564 installs fine until sugar comes up with name: and then click to change color screens. The function loops --- e.g. keeps asking me over and over name: and click to change color and will not boot further. Any ideas? Has anyone experienced this. I've tried alot of things already. I'll send in a ticket otherwise and try to downgrade to build 552. -- Regards, Steve Fullerton UCSD ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
