Re: [IAEP] [Sugar-devel] [SLOBS] GPL non compliance? was Re: GPL non-compliance, was Re: GPLv3
On Tuesday, April 26, 2011 04:14:29 pm Walter Bender wrote: > I'd love to channel the energy of this debate into writing some code to expand the utility of View Source to (a) include all of Sugar, not just the Sugar activities; and (b) make it possible from View Source to make modifications that are stored in $HOME but persistent to one's Sugar environment without having to invoke any fancy scripting in the Shell. > Maybe something we can tackle in Montevideo next week? Count me in :). -- -Andrés signature.asc Description: This is a digitally signed message part. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Google Summer of Code
Hola Carlos, La información sobre GSoC que cualquiera pueda buscar en la web va a ser mucho más exhaustiva que la que pueda dar yo en un mail. Pero puedo aportar diciendo que soy uruguayo y participé del GSoC 2009 como mentor por Sugarlabs y fue una experiencia muy enriquecedora tanto para mí como para los estudiantes que participaron. Lo considero una experiencia invaluable en el crecimiento profesional de cualquier estudiante. Es una verdadera lástima que en las universidades no se estimule la participación en el programa, ya que es una excelente manera de introducir a los estudiantes en el modelo de desarrollo open source, y además dándoles la oportunidad de aportar a proyectos (como Sugar) que tienen un impacto real en día a día de mucha gente, algo a lo que es muy difícil de acceder para un estudiante. Desde ya, quedo a disposición de quien tenga dudas sobre el programa o necesite ayuda en escribir su propuesta para aplicar al mismo. Saludos! On Thursday, December 16, 2010 12:19:22 pm Carlos Rabassa wrote: > He oído hablar mucho y muy positivamente sobre el programa > > Google Summer of Code > > http://www.google-melange.com/document/show/gci_program/google/gci2010/faqs > > Me llama la atención que en Uruguay no he oído a nadie que hable sobre su participación o sobre la existencia del programa. > > Parece sumamente interesante y gratis y con posibilidades de aprender mucho y de ganar algunos premios en dinero o incluso viajes. > > No sé más detalles y no estoy ni apoyando ni rechazando el programa ya que no lo conozco. > > Carlos Rabassa > Voluntario > Red de Apoyo al Plan Ceibal > Montevideo, Uruguay > > > > > > -- -Andrés signature.asc Description: This is a digitally signed message part. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Tuesday, August 24, 2010 11:26:23 am Chris Ball wrote: > Hi Reuben, > >> Consider the benefits of using open source software versus our >> closed source firmware and partnering with communities like >> Freifunk whose network is ~ 800 node, guifi.net is almost 10k >> nodes in Barcelona, Athens Wireless is 5k nodes. > > The fact that a custom mesh algorithm would have to run on the CPU -- > prohibiting any kind of idle-suspend -- makes it a non-starter for an > XO deployment in my eyes. Did you have any thoughts on this? We (MontevideoLibre, a free wireless community network) have been using OLSR for a while now. And though the topology in a typical OLPC scenario is very different, we've talked about assembling an image running OLSRd for a while. Anyway, I dont have time for a full response to this thread right now, but I had a conversation with smithbone and silbe a while back that may be illustrative of the worse-case scenario in terms of power consumption: silbe: I think a working PoC could gather a lot interest from deployments... aa: one thing to consider is the power draw. with libertas_tf, the host CPU needs to be powered on. yes silbe: do you have an idea of what that means in actual numbers? perhaps smithbone has a guesstimate aa: counter-question: are you thinking of running the protocol while the XO is "powered off" (screen off, everything in suspend with wake-on-WLAN) or just during regular operation? for the latter case, it might not make much of a difference, especially if "automatic power management" (automatic suspend) is disabled. Running the system is going to cost you in the 5W range. in the "powered off" case it's going to make a huge difference. I don't think it'll be able to run for more than 3h while there's any traffic. silbe: one of the things I want to find out is the convergence time of the different options aa: i.e. the time until the network/mesh is stable? yes aa: if you were in europe, you might try getting funding from the EU for that ;) silbe: also, BATMAN has a layer 2 kernel module, maybe we could make it aware of the PM state? they seem to pay some pretty sums for mesh research * aa migrates to Europe :P aa: it should just integrate into the kernel PM QoS framework I cuppose, see Documentation/power/pm_qos_interface.txt silbe: will do aa: oh, and some recent mail from me has a link to nice slides explaining the PM QoS framework silbe, smithbone: do you guys know if wol would work with libertas_tf? silbe: to sugar-devel? aa: no idea, sorry. aa: I think to de...@l.l.o silbe: found it, thanks! aa: which gen? smithbone: XO-1 aa: on XO-1 the wakeup is generated by strobing a signal to the EC. So libertas_tf would need to support strobing that signal smithbone: thanks a lot, is this documented somewhere? too bad the firmware is closed :( aa: no. because none of the systems you are talking about have open documentation smithbone: I understand aa: But I can certainly tell someone what gpio on the wlan module to strobe and for how long. -- -Andrés signature.asc Description: This is a digitally signed message part. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] The User experience/interface for Printing
On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote: > Vamsi Krishna Davuluri writes: > > So, talking to Tomeu, we agreed that for Write and Read using > > the gtkprint would be best as both support it as a printing API. > > The focus on "Write and Read" is short sighted and may lead > to inflexible solutions. Read was selected to contain the "send to print" code because Tomeu expressed some concerns about the maintainability of that code in the Journal. Also, we agreed that going through read is good for reviewing the pdf output and saving paper on badly formatted docs. > > Now, the current plan is: > > 1) We do journal printing only, albeit, the respective > > activity opens the file. > > Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf > or directly runs gs. This lets normal software, which is already > designed to output standard Postscript to lpr, work just fine. > After conversion, put the PDF into the journal. > > Better yet, just toss the file into the journal without conversion. > > BTW, this can also be implemented as a filter script that the > normal lpr program invokes for the default printer. The priority is on sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review. It is a good idea to have the code that sends docs for printing (to Moodle, a local printer, or one discovered by avahi) in a reusable module that a /usr/bin/lpr script can use. > > Now here a cross road is presented: > > > > 1) Do we use a print dialog inside each activity that can save it as pdf, > > print or export a pdf to moodle If we are going to keep everything inside Read for now. It'll be best to have the print button only in Read. The use case we had discussed was like this: open the file in Read, if its not ps/pdf Read converts it using cups-pdf, displays it, and then you can use the print button in its toolbar. The converted file gets added as a journal entry right after conversion. The datastore already contains code to hard link identical files, so disk space usage in multiple conversions is kept to a minimum. Read could add a pointer to the pdf in the original entry's metadata as well. Adding a print dialog to every activity (e.g. Adding some gtkprint support in sugar-toolkit) should be optional for GSoC. First we should concentrate on getting entries printed, and getting teacher review right. Then we can move code around for legacy support and nice "print me" buttons. > > 2) Do we use separate buttons for each of these operations? > > > > What of the user experience? > Separate buttons provides a distinction that will be important > in some environments. Some places will want immediate printing. > > For now, the "print" button can be almost the same as the other, > but with the output PDF marked for near-term deletion. > > "Make PDF" and "Print now" seem like fine names. > I agree. Just a print button for now. The PDF will be generated on startup anyway. We can have the cups-pdf local printer in the printer selection dialog when we provide other printing methods. > > The initial plan was to make Read the global printing station, > > how do you find this idea? > > Starting up Read just to print something is not nice. Read may > even cause an out-of-memory condition. For sure, there is no need > to very slowly render a big document that doesn't even need to be > seen on the screen. This is to encourage review and to keep the code away from the Journal. The code can then be moved to Glucose. Also, distributing a modified Read for testing will be considerably easier than patching the Journal. > > the teacher checks his print page in moodle, views the file (either > > through fancy javascript or a download) and approves/disapproves > > for printing. Kennedy then logs into his moodle print page and > > checks if the job was success or not, and if he has a comment from > > his teacher. > > I can barely imagine that happening in a real classroom. Try this: > > The student brings his XO to the teacher's desk, with his work shown > on the screen. The teacher looks at the work, then lets the student > plug his XO into a printer which sits on the teacher's desk. > > > Printing resources can be very expensive for most schools, so > > the system should include a way for students to submit jobs to a > > queue and for an administrator to preview and approve or denie them. > > Tux Paint can rate limit a student's printing. For example, a setting > of 60 will be once per minute. > > Do not forget that this issue is more social than technical. In addition > to any discipline, the teacher can simply turn off the printer. This is > advisable in any case; many printers use excessive power in standby. I dont see a teacher having a printer on her desk. Most schools here in Uruguay (and I dare say in Perú) don't even have printers. If there is one, it will be where the server/administration is. And possibly locked in a cage (like we have the serve
[IAEP] Ceibal volunteers 2008 video summary
A beautiful video put together by Leticia Romero from RAP Ceibal (Ceibal Plan Support Network) summarizing their activities throughout 2008: http://www.youtube.com/watch?v=CpUnArGIoEU (Some of you will recognize the characters at 8:22 :P) I hope everyone enjoyed a merry Christmas and I wish everyone a happy new year! -- -Andrés signature.asc Description: This is a digitally signed message part. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
