Re: [sugar] SMS messaging
Le mercredi 23 juillet 2008 à 12:38 -0400, Ankur Verma a écrit : I can run a bash/python script upon the reception of the message with the message parameters. This makes it flexible enough to call any application. Then I think you should write a Python application which connect to the jabber server, find the buddy and send him the message. As a start I suggest you to take a look on the Telepathy spec [1] and telepathy-python examples. G. [1] http://telepathy.freedesktop.org/spec.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
As per our earlier discussion, the method at present is to use roster.py, which you are planning to remove in the next versions. As roster.py also uses Telepathy to get the nicks of XO who have subscribed or are friends, are there any alternative functions which I can use to fetch the list of XOs? I am ready to look more into telepathy specs, but I am curious to know the answer. Thank you. Best, Ankur Verma On Thu, Jul 24, 2008 at 2:51 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mercredi 23 juillet 2008 à 12:38 -0400, Ankur Verma a écrit : I can run a bash/python script upon the reception of the message with the message parameters. This makes it flexible enough to call any application. Then I think you should write a Python application which connect to the jabber server, find the buddy and send him the message. As a start I suggest you to take a look on the Telepathy spec [1] and telepathy-python examples. G. [1] http://telepathy.freedesktop.org/spec.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] QUERY REGARDING INTERFACING OF TOOLBAR
Hi,
where is the xocom source repository?
I know nothing about xocom, but I recommend you to code a simple
python-only activity first to familiarize with that part of the
problem, and only then coming back to the SocialCalc Activity. Take a
look to this activity:
http://dev.laptop.org/~marco/Edit-1.xo
http://dev.laptop.org/git?p=users/marco/edit-activity;a=blob;f=editactivity.py;h=bb2e98e27f236e716fb47faad952ac35fb827ab9;hb=HEAD
Good luck,
Tomeu
2008/7/24 Preeti KS [EMAIL PROTECTED]:
Dear all,
I have been working on the toolbar of the SocialCalc Activity. In this
activity, a Spreadsheet was being made. The main programme has been written
in Javascript. whereas the function call has been made from Python. Hence, a
package called xocom was made to felicitate communication between JS and
Python.
I made the toolbar in Python, and used xocom to create the webview,etc. I
also managed to interface the toolbar.py file with the socialcalc.py file,
however, as I am not very adept with JS, I am facing problems interfacing
the toolbar.py file with the Javascript file. I have attached the relevent
files with this email and also at
http://wiki.laptop.org/go/Image:SocialCalc-toolbar.zip .
My toolbar.py file is as follows, these are some code snippets:
This is the main spreadsheet activity toolbar, It has used xocom to create
the webview..
class SpreadSheetActivityToolbar:
def __init__(self, activity, toolbox, self_canvas):
self._activity = activity
self.set_canvas( xocom.create_webview() )
self._activity_toolbar = toolbox.get_activity_toolbar()
self._keep_palette = self._activity_toolbar.keep.get_palette()
.
Then, I have created another class, for the edit toolbar. Its definition is
as follows:
class SpreadsheetEditToolbar(EditToolbar):
def __init__(self, toolbox, self_canvas):
EditToolbar.__init__(self)
self.set_canvas( xocom.create_webview() )
.
This is followed by the general definition of edit toolbar,
copy,paste,undo,redo, etc. There is also a viewtoolbar class, for viewing it
on hulahoop.
Here are the details of the SocialCalc.py file:
To interface it with toolbar.py, I have imported the classes from this file
as:
import toolbar
from toolbar import SpreadSheetActivityToolbar, SpreadsheetEditToolbar,
ViewToolbar
Then, while creating the toolbar, I have called these functions as:
toolbox = activity.ActivityToolbox(self)
self.set_toolbox(toolbox)
toolbox.show()
Separately calling edit toolbar:
self._edit_toolbar = SpreadsheetEditToolbar(self, self._edit_toolbar,
set_canvas)
toolbox.add_toolbar(_('Edit'),self._edit_toolbar)
self._edit_toolbar.show()
And similarly calling the Viewtoolbar class:
view_toolbar = ViewToolbar (self.set_canvas)
self.set_canvas.show()
Now, my problem is that, the xocom class connects the socialcalc.py file
with the Javascript file, socialcalc.js and xocom.js. I am unable to make
out, whether I have to make changes in the JS file, and what changes to
make.
I would be obliged if someone who has been designing toolbars, can help me
out with this interfacing problem.
Thanks and regards
KS Preeti,
Team Member,
SocialCalc Team
___
Devel mailing list
[EMAIL PROTECTED]
http://lists.laptop.org/listinfo/devel
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Le jeudi 24 juillet 2008 à 03:36 -0400, Ankur Verma a écrit : As per our earlier discussion, the method at present is to use roster.py, which you are planning to remove in the next versions. Humm not really. Using the roster is and will always be a sane way to find contacts. But, as you can guess, it assumes that the contact is in your roster. Currently this is a sane assumption because of the shared roster hack. But when we'll drop it, that won't be true anymore. As roster.py also uses Telepathy to get the nicks of XO who have subscribed or are friends, are there any alternative functions which I can use to fetch the list of XOs? I am ready to look more into telepathy specs, but I am curious to know the answer. The plan with Gadget is to allow user to request random buddies (and activities) or perform search based on different criteria. As you can see on [1], currently only search based on buddy properties is implemented but we plan to add alias search soon (maybe next week if you really need it). So for now, I suggest you to use a server with the shared roster hack or manually subscribe your SMS user with a test buddy for your tests. So you could test most of the part of your app and just change it to use alias search later. G. [1] http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar mtg reminder, 24rd July 2008 --- 17.00 UTC --- irc.freenode.net, #sugar-meeting
topics are: * update of the week (e.g. process changes) * roadmap * what are the latest bugs, where can we need help on * introduction of new developers (optional) Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] QUERY REGARDING INTERFACING OF TOOLBAR
Thanks for the quick response..The xocom is at
http://github.com/lukec/xocom/tree/master
I will definitely go through the codes you have sent. After studying that, I
will try to get back to SocialCalc again..
Regards
Preeti
On 7/24/08, Tomeu Vizoso [EMAIL PROTECTED] wrote:
Hi,
where is the xocom source repository?
I know nothing about xocom, but I recommend you to code a simple
python-only activity first to familiarize with that part of the
problem, and only then coming back to the SocialCalc Activity. Take a
look to this activity:
http://dev.laptop.org/~marco/Edit-1.xo
http://dev.laptop.org/git?p=users/marco/edit-activity;a=blob;f=editactivity.py;h=bb2e98e27f236e716fb47faad952ac35fb827ab9;hb=HEAD
Good luck,
Tomeu
2008/7/24 Preeti KS [EMAIL PROTECTED]:
Dear all,
I have been working on the toolbar of the SocialCalc Activity. In
this
activity, a Spreadsheet was being made. The main programme has been
written
in Javascript. whereas the function call has been made from Python.
Hence, a
package called xocom was made to felicitate communication between JS and
Python.
I made the toolbar in Python, and used xocom to create the
webview,etc. I
also managed to interface the toolbar.py file with the socialcalc.py
file,
however, as I am not very adept with JS, I am facing problems interfacing
the toolbar.py file with the Javascript file. I have attached the
relevent
files with this email and also at
http://wiki.laptop.org/go/Image:SocialCalc-toolbar.zip .
My toolbar.py file is as follows, these are some code snippets:
This is the main spreadsheet activity toolbar, It has used xocom to
create
the webview..
class SpreadSheetActivityToolbar:
def __init__(self, activity, toolbox, self_canvas):
self._activity = activity
self.set_canvas( xocom.create_webview() )
self._activity_toolbar = toolbox.get_activity_toolbar()
self._keep_palette = self._activity_toolbar.keep.get_palette()
.
Then, I have created another class, for the edit toolbar. Its definition
is
as follows:
class SpreadsheetEditToolbar(EditToolbar):
def __init__(self, toolbox, self_canvas):
EditToolbar.__init__(self)
self.set_canvas( xocom.create_webview() )
.
This is followed by the general definition of edit toolbar,
copy,paste,undo,redo, etc. There is also a viewtoolbar class, for viewing
it
on hulahoop.
Here are the details of the SocialCalc.py file:
To interface it with toolbar.py, I have imported the classes from this
file
as:
import toolbar
from toolbar import SpreadSheetActivityToolbar, SpreadsheetEditToolbar,
ViewToolbar
Then, while creating the toolbar, I have called these functions as:
toolbox = activity.ActivityToolbox(self)
self.set_toolbox(toolbox)
toolbox.show()
Separately calling edit toolbar:
self._edit_toolbar = SpreadsheetEditToolbar(self,
self._edit_toolbar,
set_canvas)
toolbox.add_toolbar(_('Edit'),self._edit_toolbar)
self._edit_toolbar.show()
And similarly calling the Viewtoolbar class:
view_toolbar = ViewToolbar (self.set_canvas)
self.set_canvas.show()
Now, my problem is that, the xocom class connects the socialcalc.py file
with the Javascript file, socialcalc.js and xocom.js. I am unable to make
out, whether I have to make changes in the JS file, and what changes to
make.
I would be obliged if someone who has been designing toolbars, can help
me
out with this interfacing problem.
Thanks and regards
KS Preeti,
Team Member,
SocialCalc Team
___
Devel mailing list
[EMAIL PROTECTED]
http://lists.laptop.org/listinfo/devel
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] libabiword, libabiword-plugins, pyabiword and abiword merged
Tomeu Vizoso wrote: On Wed, Jul 23, 2008 at 10:34 PM, J.M. Maurer [EMAIL PROTECTED] wrote: On Wed, 2008-07-23 at 22:24 +0200, J.M. Maurer wrote: Hi all, I've merged libabiword, libabiword-plugins and pyabiword from OLPC with the official Fedora AbiWord package. libabiword-plugins only existed in OLPC-land, and has been retired. Everything is built through koji now and joyride should build again. If there are any problems (for example, dragging in too many deps on OLPC), please let me know. Sorry for all the build breakages in the process. It wasn't exactly a trivial merge. Oh, this also means that libabiword in joyride is the latest upstream version again, instead of some random SVN snapshot from Nov. 2007. Is everything needed for Sugar in upstream AbiWord, meaning other distributions packaging it get all the functionality as well? Jani ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: 2) Sugar would run more smoothly on-XO if jhbuild were retired. I think this is a good point in the abstract. Do any frequent contributors *not* have an XO? I approve of retiring jhbuild, and handing out XO's to Sugar contributors, but you've really got the question backwards: = Do any frequent contributors have ONLY an XO? = Yes, I've taken it on a tangent, as I promised in my boilerplate. Thanks for getting back to the topic. Is the question really best phrased as you did? Are you really asking should the contributor community only use XOs? It seems you're asking how can we turn our XO deployment kids into contributors, which is a great question. I think the way forward is to raise some awareness (as you're doing) and constructively move the discussion forward. I've seen lots of high flying rhetoric about Sugar being maintainable and extensible by kids with their XO's, because it's in an easy interpreted language shipped in source, etc. You have almost 500,000 units in the field (admittedly in younger kids). Seen any Python prodigies contributing yet? The sound-bite rhetorical question distracts from your later good points. Especially given the point is educating kids, I'm not so concerned that kids learning english and maths haven't sent sugar patches in yet :). But the tools needed to be a contributing part of the Sugar community don't run on the XO. [...] Merely installing the change without trashing his XO's entire GUI with a typo or missing Python file is tricky. Indeed! How can we as the community improve the extensibility while letting the core people get on with developing the core (and yes, I know the core has to be extensible, and I think it's good to keep raising the point; but we also need to *do* something about it - any ideas? I would be very interested in working on some, and coming up with some when I'm finished my one or two patches I'm working on now). If we want the kids who *love* their machines to come to *know* and *evolve* their machines, there's a lot more work to be done. Indeed. I quote this not for the mindless me too gnu++ kthx but to highlight it more - I think it gets lost a bit in your detailed points. In many ways the unique XO UI and collab setup make the learning curve steeper, not easier. I don't know this to be true, and I suspect it to be a distracting falsehood. But let's try to address the more fundamental issues (like no diff / diff-like utility / tools) you raised earlier. John Sugar is hung up in its own maintenance machinery. I don't think you (only) mean Sugar here. Very interesting comments, btw. Thanks. Martin pgpNcSDK38Cod.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] libabiword, libabiword-plugins, pyabiword and abiword merged
On Thu, 2008-07-24 at 13:10 +0300, Jani Monoses wrote: Tomeu Vizoso wrote: On Wed, Jul 23, 2008 at 10:34 PM, J.M. Maurer [EMAIL PROTECTED] wrote: On Wed, 2008-07-23 at 22:24 +0200, J.M. Maurer wrote: Hi all, I've merged libabiword, libabiword-plugins and pyabiword from OLPC with the official Fedora AbiWord package. libabiword-plugins only existed in OLPC-land, and has been retired. Everything is built through koji now and joyride should build again. If there are any problems (for example, dragging in too many deps on OLPC), please let me know. Sorry for all the build breakages in the process. It wasn't exactly a trivial merge. Oh, this also means that libabiword in joyride is the latest upstream version again, instead of some random SVN snapshot from Nov. 2007. Is everything needed for Sugar in upstream AbiWord, meaning other distributions packaging it get all the functionality as well? Yes, as long as they compile AbiWord and plugins with --enable-libabiword (this will be default in 2.8.x). Marc ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
On Thu, 2008-07-24 at 06:16 -0400, Greg Smith wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. The sugar activity developers have been for 2.5 years as well :) [snip] - Activity or main GUI responsiveness to cursor It seems to me that the activities are a little slow. e.g. when I try to draw a line in paint, it takes a little while (maybe 100s of ms but noticeable) for the line to show on the screen. Similar with cursor placement in write or in the journal/home. Has anyone else noticed that? Is that due to CPU cycles or screen refresh or something else? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? This may cost us significantly if we don't show improvement. Send me ideas. Any quick wins would be considered, even if they have a downside in another metric. Quick wins are ofcourse fine, but *please finally* also invest in a fundamental solution to the problem. Hire/contract someone to properly investigate all the performance issues down from the kernel all the way up to the sugar/activity level. As long as I've been around (2.5 years or so), I've been hearing from developers that they are really eager to work on the performance issues, but have 'always' being held back by being forced to go for the quick wins/hacks. Cheers! Marc ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
I am steadfast in the opinion that stability and predictability are much more important goals for 8.2 than trying to make significant speed improvements. Also, do you know what build Miguel was basing his assessment on? -walter On Thu, Jul 24, 2008 at 6:16 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Focus is on improving this in 8.2.0. Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? - File/activity open Can we improve this? A piece of the latency here may be due to a large Journal being much slower. Can we chunk journal reads or otherwise improve the speed of opening files? Can we speed up journal access in its own GUI too? - File save What is the bottle neck on save? Let's create a test case for this. - Task switching I've seen some threads on this. Can someone summarize it and give me a hard number to show how we have improved? - Activity or main GUI responsiveness to cursor It seems to me that the activities are a little slow. e.g. when I try to draw a line in paint, it takes a little while (maybe 100s of ms but noticeable) for the line to show on the screen. Similar with cursor placement in write or in the journal/home. Has anyone else noticed that? Is that due to CPU cycles or screen refresh or something else? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? This may cost us significantly if we don't show improvement. Send me ideas. Any quick wins would be considered, even if they have a downside in another metric. I'll come back with more details on their specific concerns as soon as I get it. BTW this was raised by the kids in their blog several months ago. See the first link here: http://wiki.laptop.org/go/9.1.0#Unadorned_and_unedited_user_feedback Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
+1 to Marc's comment as well, that was posted while I was writing mine. -walter On Thu, Jul 24, 2008 at 7:39 AM, Walter Bender [EMAIL PROTECTED] wrote: I am steadfast in the opinion that stability and predictability are much more important goals for 8.2 than trying to make significant speed improvements. Also, do you know what build Miguel was basing his assessment on? -walter On Thu, Jul 24, 2008 at 6:16 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Focus is on improving this in 8.2.0. Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? - File/activity open Can we improve this? A piece of the latency here may be due to a large Journal being much slower. Can we chunk journal reads or otherwise improve the speed of opening files? Can we speed up journal access in its own GUI too? - File save What is the bottle neck on save? Let's create a test case for this. - Task switching I've seen some threads on this. Can someone summarize it and give me a hard number to show how we have improved? - Activity or main GUI responsiveness to cursor It seems to me that the activities are a little slow. e.g. when I try to draw a line in paint, it takes a little while (maybe 100s of ms but noticeable) for the line to show on the screen. Similar with cursor placement in write or in the journal/home. Has anyone else noticed that? Is that due to CPU cycles or screen refresh or something else? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? This may cost us significantly if we don't show improvement. Send me ideas. Any quick wins would be considered, even if they have a downside in another metric. I'll come back with more details on their specific concerns as soon as I get it. BTW this was raised by the kids in their blog several months ago. See the first link here: http://wiki.laptop.org/go/9.1.0#Unadorned_and_unedited_user_feedback Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
instead of just turtle programs and gooey smalltalk... Cannot let this one slip by uncommented on. Etoys is one place where kids are doing real programming, as a means of achieving fluency about many powerful ideas, not just syntax. But I unaware that children have made contributions to Squeak yet. -walter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Reviews report
= New requests = sugar-shell enters in infinite loop after a failed shutdown http://dev.laptop.org/ticket/7566 cp: Inconsistent behavior after changing the xo color http://dev.laptop.org/ticket/7560 = Approved requests = palettes in journal give false information http://dev.laptop.org/ticket/7600 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
Hi Guys, I need short term options and longer terms options. What do we know already? Where are the bottle necks and how much work would it be to improve them? Stability is key and we're not going to sacrifice that for 8.2.0. Regardless we need scoping on performance improvement options and then we can pick an appropriate time frame and balance that against other priorities. Get me started with what we have already discovered, if anything. Thanks, Greg S Walter Bender wrote: +1 to Marc's comment as well, that was posted while I was writing mine. -walter On Thu, Jul 24, 2008 at 7:39 AM, Walter Bender [EMAIL PROTECTED] wrote: I am steadfast in the opinion that stability and predictability are much more important goals for 8.2 than trying to make significant speed improvements. Also, do you know what build Miguel was basing his assessment on? -walter On Thu, Jul 24, 2008 at 6:16 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I just got word from a decision maker that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Focus is on improving this in 8.2.0. Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? - File/activity open Can we improve this? A piece of the latency here may be due to a large Journal being much slower. Can we chunk journal reads or otherwise improve the speed of opening files? Can we speed up journal access in its own GUI too? - File save What is the bottle neck on save? Let's create a test case for this. - Task switching I've seen some threads on this. Can someone summarize it and give me a hard number to show how we have improved? - Activity or main GUI responsiveness to cursor It seems to me that the activities are a little slow. e.g. when I try to draw a line in paint, it takes a little while (maybe 100s of ms but noticeable) for the line to show on the screen. Similar with cursor placement in write or in the journal/home. Has anyone else noticed that? Is that due to CPU cycles or screen refresh or something else? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? This may cost us significantly if we don't show improvement. Send me ideas. Any quick wins would be considered, even if they have a downside in another metric. I'll come back with more details on their specific concerns as soon as I get it. BTW this was raised by the kids in their blog several months ago. See the first link here: http://wiki.laptop.org/go/9.1.0#Unadorned_and_unedited_user_feedback Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: [some interesting points] Sorry my meta-comments snuck in - they aren't relevant, and I didn't follow my own advice...I retract them (I'm sure you can tell what parts they were). = Do any frequent contributors have ONLY an XO? = As I've been fiddling around with a patch or two, my jhbuild has been broken due to x86_64 Xephyr F9 brokenness that's been recently fixed (thanks dodji, if you're listening, and cjb/marco for pushing), so please count me among those contributors who only have an XO (temporarily). But the tools needed to be a contributing part of the Sugar community don't run on the XO. [...] Merely installing the change without trashing his XO's entire GUI with a typo or missing Python file is tricky. After restarting X/Sugar so often to test patches for #6995, I've developed an itch for a Sugar-shell-REPL in Pippy, or something similar. Perhaps that's one way for people in the field to tinker. Of course there are diff/code browsing issues still. John Martin pgpozqXekP4W5.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
On Thu, Jul 24, 2008 at 06:16:33AM -0400, Greg Smith wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Focus is on improving this in 8.2.0. Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? - File/activity open Can we improve this? A piece of the latency here may be due to a large Journal being much slower. Can we chunk journal reads or otherwise improve the speed of opening files? Can we speed up journal access in its own GUI too? - File save What is the bottle neck on save? Let's create a test case for this. - Task switching I've seen some threads on this. Can someone summarize it and give me a hard number to show how we have improved? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? My impression is that all of the above areas of user experience are bound by filesystem io performance and can be greatly affected by changing the compression scheme which we use on the jffs2 filesystem. Tests by NoiseEHC (and to a less rigorous extent by myself) suggest that moving to LZO compression would greatly speed up read and write to the data store (by at least several times). The problem with such improvements is that often they require changes in low-level system compononents. In the case of LZO compression we would have to reformat the root filesystem and modify the kernel configuration. The simplest way to execute this is via a reflash of an existing system. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] libabiword, libabiword-plugins, pyabiword and abiword merged
On Thu, Jul 24, 2008 at 1:20 PM, J.M. Maurer [EMAIL PROTECTED] wrote: On Thu, 2008-07-24 at 13:10 +0300, Jani Monoses wrote: Tomeu Vizoso wrote: On Wed, Jul 23, 2008 at 10:34 PM, J.M. Maurer [EMAIL PROTECTED] wrote: On Wed, 2008-07-23 at 22:24 +0200, J.M. Maurer wrote: Hi all, I've merged libabiword, libabiword-plugins and pyabiword from OLPC with the official Fedora AbiWord package. libabiword-plugins only existed in OLPC-land, and has been retired. Everything is built through koji now and joyride should build again. If there are any problems (for example, dragging in too many deps on OLPC), please let me know. Sorry for all the build breakages in the process. It wasn't exactly a trivial merge. Oh, this also means that libabiword in joyride is the latest upstream version again, instead of some random SVN snapshot from Nov. 2007. Is everything needed for Sugar in upstream AbiWord, meaning other distributions packaging it get all the functionality as well? Yes, as long as they compile AbiWord and plugins with --enable-libabiword (this will be default in 2.8.x). Yay! Abiwidget for everybody! Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Textbook (was Re: [OLPC-Games] Physics --
Yoshiki, I don't want sound to be a jerk..., but a game like Asteroids is so right on the sweet spot of Etoys (take a look at the existing Lunar Lander, and think about extending it with better controls and rotation). And, the biggest advantage of that route I think is all scripts can be written by kids and they can experiment different scripts and parameters. That would be more interesting on educational side. I won't disagree with those points at all. Like I said, I'm coming to this from the back door. I started down this path to: 1) Get more familiar with Python, by having something to modify rather than starting from scratch -- with the added idea that it should be far enough off the main line that it could be my sandbox. 2) Understand what it takes to get an activity running in Sugar. 3) See what it took to make PyGame based games (there are a lot of them out there) more suitable for the XO. 4) Better understand the Sugar/XO development community, environment, and system. Along the way I discovered that I really didn't like the code I was playing with and thought that refactoring it, and by doing so create some classes that would be applicable to other Physics based games, would be a good exercise. Bob ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
Hi Tomeu, Thanks for the info. No change in plan right now. I'm just looking for background info and ideas. Please forge ahead as already planned for now. Thanks, Greg S Tomeu Vizoso wrote: On Thu, Jul 24, 2008 at 12:16 PM, Greg Smith [EMAIL PROTECTED] wrote: I'll come back with more details on their specific concerns as soon as I get it. The good news is that so little work has gone into this area that improving is easy. The bad news is that we currently have nobody to work on that :/ If we are serious about improving performance, I suggest to make a list of the perceived performance problems, then try to come up with measurements that match as well as possible. In some cases will be easier, in some cases will be harder. Only then we can start to discuss how to improve it. Also, we'll need to be ready to do one of these: - move some new features from 8.2.0 to 9.1.0, - move the 8.2.0 release later (perhaps merging with 9.1.0?), - lower our general quality standards. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
On Thu, 2008-07-24 at 06:16 -0400, Greg Smith wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Uruguay run build 656 (or a modified version). If I remember correctly, update1 includes several performance improvements (faster activity start, etc). Daniel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] X error building Sugar Appliance
I am trying to build a raw disk appliance of the sugar desktop using the appliance tools at [1]. You can see the kickstart file which I am using [2] which is based off of one I found in the repo [3]. I have run into an error when starting X, I get error setting MTRR Invalid Argument (22) error setting MTRR Function Not Implemented (38) After some google research, I have found that I echo echo disable=0 /proc/mtrr I can get a bit further. Couple of questions: 1. Is [3] the most current livecd kickstart file? 2. Has anyone seen this error before? Thanks! -- bk [1] http://www.thincrust.net/tooling.html [2] http://www.thincrust.net/download/sugar.ks [3] http://dev.laptop.org/git?p=users/marco/sugar-livecd;a=summary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
Hi Greg, Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? The best thing we can do here is to free up someone to work on #7395: we made huge gains in activity startup, and have lost them again with the switch to Fedora 9, until someone can work on having Rainbow launched from Upstart after X has launched. Normally Michael would work on this, but he's swamped. It might be possible to get help with this via a call for help on the new fedora-olpc list, if there's anyone there with Upstart knowledge. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] X error building Sugar Appliance
On Thu, Jul 24, 2008 at 5:02 PM, Bryan Kearney [EMAIL PROTECTED] wrote: I am trying to build a raw disk appliance of the sugar desktop using the appliance tools at [1]. You can see the kickstart file which I am using [2] which is based off of one I found in the repo [3]. Awesome. I didn't know about the appliance tools but I was really hoping for something like that when I worked on the livecd. I have run into an error when starting X, I get error setting MTRR Invalid Argument (22) error setting MTRR Function Not Implemented (38) After some google research, I have found that I echo echo disable=0 /proc/mtrr I can get a bit further. Couple of questions: 1. Is [3] the most current livecd kickstart file? Yeah. We are near to a release so I didn't have much time to work on the livecd lately. I would like to integrate your changes so that we can use the same kickstart for both the livecd and the appliance. 2. Has anyone seen this error before? Nope :( I don't think I run into it with the livecd... Can you get sugar to start by disabling /proc/mtrr? Or did you run into more issues? Thanks, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
On Thu, Jul 24, 2008 at 6:29 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello Greg, you marked one the RTL tickets as a blocker. Is RTL support in general considered a release blocker? If so, probably most or all of the tickets on the RTL tracker bug should be marked as such (and there might very well be more). http://dev.laptop.org/ticket/6808 Also, I think we should get ASAP some people with knowledge of the bidi scripts we care about to revise the whole UI. If we wait more, we risk having to do invasive changes too late in the cycle. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
On Thu, Jul 24, 2008 at 6:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 6:29 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello Greg, you marked one the RTL tickets as a blocker. Is RTL support in general considered a release blocker? If so, probably most or all of the tickets on the RTL tracker bug should be marked as such (and there might very well be more). http://dev.laptop.org/ticket/6808 Also, I think we should get ASAP some people with knowledge of the bidi scripts we care about to revise the whole UI. If we wait more, we risk having to do invasive changes too late in the cycle. To be honest, it's already pretty late :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Low space UI
Hello, we have a few UI blockers assigned for the low space issues. Sugar should provide messages indicating when NAND is getting full and critically full http://dev.laptop.org/ticket/7588 Journal writes which fail due to insufficient space should provide useful feedback. http://dev.laptop.org/ticket/7589 Removing content from Journal should work even if NAND is full. http://dev.laptop.org/ticket/7590 And then there is the one about making Sugar work even with full disk, which Erik is trying to address outside Sugar. There was no clear consensus in the meeting about solving the issue is a whole, so we don't know if we should be actually considering them blockers (and get them done ASAP) or not. The first two will require to break the string freeze once again. Greg, Michael, can you please clarify? Thanks, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Xephyr rpms
Hello, ajax built new Fedora 9 rpms which should contain the fix for Xephyr on x86_64. http://koji.fedoraproject.org/koji/buildinfo?buildID=57371 https://admin.fedoraproject.org/updates/F9/pending/xorg-x11-server-1.4.99.906-1.fc9 Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
Hi Guys, RTL is a blocker and it should be all RTL issues unless we can show that they are cosmetic or there is an acceptable work around. The reason they are show stoppers is that we have major Arabic deployments planned for this fall and winter (northern hemisphere). I believe these are regression bugs in that RTL works correctly (better?) in previous releases. Some of the deployments will start before 8.2.0 is out but we need an upgrade path for them ASAP per NAND Full bug. Some of the ones that are planned for later in the year will go to places where it will be extremely hard to upgrade them. In short I do want these all marked blockers, especially if they are regressions. I'm not sure what milestone you think we will miss, but I'm inclined to hold the release to fix these if its not too long a delay. What do we need to do to get some people with knowledge of bidi scripts to help? I have asked all deployments to come up with contacts and I'll keep on them to rally the bidi community if I can find it. By all means, send out the call wherever you can find an audience! Thanks, Greg S Marco Pesenti Gritti wrote: On Thu, Jul 24, 2008 at 6:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 6:29 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello Greg, you marked one the RTL tickets as a blocker. Is RTL support in general considered a release blocker? If so, probably most or all of the tickets on the RTL tracker bug should be marked as such (and there might very well be more). http://dev.laptop.org/ticket/6808 Also, I think we should get ASAP some people with knowledge of the bidi scripts we care about to revise the whole UI. If we wait more, we risk having to do invasive changes too late in the cycle. To be honest, it's already pretty late :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
On Thu, Jul 24, 2008 at 6:55 PM, Greg Smith [EMAIL PROTECTED] wrote: I believe these are regression bugs in that RTL works correctly (better?) in previous releases. This seems very unlikely. We basically never tried to support RTL so far... Thanks for clarifying. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
Marco, Thanks for asking for clarification on this issue. At present, Greg and I disagree about whether this cluster of issues should block the 8.2.0 release and are working with Kim and Robert to resolve our disagreement. However, in order to make good decisions, it would be very helpful if the Sugar/X team along with Sayamindu (and any other people interested in the issue) could write up a short essay explaining all of the current bugs in this area, what plans we could pursue in order to close them, and what it might cost to exercise each plan. In the meantime, I will remove the blocks:8.2.0 tag from these tickets until we reach our decision. Sorry for the miscommunication, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Textbook (was Re: [OLPC-Games] Physics -- Newtonian, mechanics.. for kids!)
Am 24.07.2008 um 00:19 schrieb Yoshiki Ohshima: I don't want sound to be a jerk..., but a game like Asteroids is so right on the sweet spot of Etoys (take a look at the existing Lunar Lander, and think about extending it with better controls and rotation). Actually, I found it surprisingly hard to do ... - Bert - And, the biggest advantage of that route I think is all scripts can be written by kids and they can experiment different scripts and parameters. That would be more interesting on educational side. (Just for the record that I read these emais, albeit slowly^^;) And thank you Edward again for thinking about the contents aspect of the project. -- Yoshiki ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Congratulations! but Sugar sucks
(Foreword: I originally intended to send this e-mail after the release of 8.2.0, but I have been convinced to send it earlier in order to prompt discussion) Dear OLPC developers, Congratulations on your work so far towards 8.2.0, with its new UI, new underpinnings, and thousands of individual improvements. It took years of effort to get this far, and a tremendous amount has been done to reinvent the entire notion of a software stack to better serve the educational needs of children. This release will be a triumph. Unfortunately, it is also an abysmal failure. There is hardly a worse operating environment available than Sugar as it currently stands. In addition to an amazing variety of terrible bugs, this failure is due to a handful of major missing features. I list here six major missing features, and what can be done about them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding. 1. The datastore Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements. Solution: There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority. 2. OS Updates We now have hundreds of thousands of laptops deployed in the field, running a variety of OS versions. OLPC cannot afford to support a multitude of decrepit versions, and children cannot afford to suffer defects that have long since been fixed. We need a reliable, fast, update system that does not rely on the network, so that children everywhere can move to the latest version of Sugar without losing their data. The update system must support tremendously invasive upgrades, like repartitioning the NAND and replacing JFFS2, because we expect to do this in short order. Solution: A secure usb autoreinstallation stick is required. It is not technically challenging to implement, but it must be made a priority, and then be made widely available and idiot-proof. 3. File Sharing Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network. This is the most basic possible network functionality --- FTP was standardized in 1971 --- but it is completely missing from our system. Solution: A number of technical proof-of-concept programs have been written for distributing files, using methods like HTTP over stream tubes and Cerebro's Teleport. There is an excellent set of UI mockups for this functionality. All that is left is to Get It Done. 4. Activity Modification A keystone of the Sugar design has always been the user's ability to edit any Activity, and to cement this a View Source key was designed right into the hardware. This functionality is simply missing, and that prevents us from making our principal claim regarding an emphasis on user modification. Solution: Develop must be polished, finished, and included by default. This will require modifications to the core system, in order to support an endless variety of slightly modified Activities. It will also require work on the Develop program itself. If volunteer efforts are not moving fast enough, OLPC must ensure that someone is working on the problem as a professional. 5. Bitfrost Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. Given Sugar's competitive status against Windows XO, this failing threatens the very existence of the project. The Sugar designs have long stated that safely running untrusted code from a classmate is a key goal for learning, but the current software accomplishes precisely the opposite. Solution: NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on Sugar security (after activation) has either left OLPC or moved into another role. Someone must be assigned to continue the security work, or it will certainly never make progress. Anyone who _does_ take on this challenge will start from a much better position than
Re: [sugar] Xephyr rpms
On Thu, Jul 24, 2008 at 06:50:25PM +0200, Marco Pesenti Gritti wrote: Hello, ajax built new Fedora 9 rpms which should contain the fix for Xephyr on x86_64. Thanks - that's awesome. Marco Martin pgpXdhVrtlKb3.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Textbook (was Re: [OLPC-Games] Physics -- Newtonian, mechanics.. for kids!)
At Thu, 24 Jul 2008 14:23:07 -0400, Bert Freudenberg wrote: Am 24.07.2008 um 00:19 schrieb Yoshiki Ohshima: I don't want sound to be a jerk..., but a game like Asteroids is so right on the sweet spot of Etoys (take a look at the existing Lunar Lander, and think about extending it with better controls and rotation). Actually, I found it surprisingly hard to do ... Really? I made a version during the hands on session of last SqueakFest. -- Yoshiki ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
I'm not familiar with the details of the Rainbow implementation, but I question this claim: Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. My understanding was that something called an 'Activity' would be assigned its own userid-groupid. The standard Linux permissions would prevent such an 'Activity' from messing up the system. I agree that as of this date, the 'su' (or its equivalent) provision sucks -- a decision has been made that the kid does not have to enter a password, even if one has been defined for root. But that can be improved to not remain the 'least secure ever'. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: | I'm not familiar with the details of the Rainbow implementation, but | I question this claim: | | Sugar, as it currently stands, is among the least secure operating systems | ever, far less secure than any modern Linux or Windows OS. I can easily | write an Activity that, when run by the user, escalates to root privileges | and does anything I like with the system. | | My understanding was that something called an 'Activity' would be | assigned its own userid-groupid. The standard Linux permissions | would prevent such an 'Activity' from messing up the system. The problem is the loophole'd activities: Journal and Terminal. These two activities run with the full privileges of the user. The identity of an activity is simply its D-Bus name. Therefore, if I write an Activity and set its D-Bus name to be org.laptop.TerminalActivity, it will run as user olpc, not as an isolated user. It will therefore have root access via passwordless su. This loophole was meant as a temporary workaround, to be replaced once Sugar acquired a secure mechanism for providing specific Activity bundles with elevated privileges. I'm merely suggesting that it is time to implement that mechanism. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI3QEACgkQUJT6e6HFtqSOKQCcCwW0dNZ9nnrHgF/bzEuU0YPj wdUAn2Vnfx+RVw95W/fUXqtcQVF2aGSI =bs5K -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar mtg minutes, 24th July 2008
Hi, these are the minutes of today's sugar developer meeting. Please check the minutes and complete what I may have missed. http://sugarlabs.org/go/DevelopmentTeam/Meetings#Thursday_July_24_2008_-_17.00_.28UTC.29 Thanks, Tomeu = Update = People is working on bugs, Marco focused on Browse, he's back full time in the team. Tomeu on miscellanea bugs, worked with Riccardo Lucchese on performance (he's interning in OLPC this summer). Sayamindu is planning future work on the Read and Terminal activities. = Change in the translation process = After changes that break the string freeze get into git, the development team should notify the localization list, so the localization team can update Pootle. There are some worries about the frequent string freeze breaks, we hope translators will understand and things will get better for the next release. = Roadmap = David Farning suggested that some preliminary work happened on identifying the areas that will be worked on in the next releases. Benjamin Schwartz argued that people should focus completely on the current release instead, and let future planning for later. Three big areas of work that is sorely needed by deployments are collaboration, performance and datastore. How can we improve stability at the same time? Benjamin thinks that we should focus for two weeks on planning, and close all questions then. Walter wants to see documents about the architecture of the datastore and collaboration. Thinks that we should aim for 3 months of design work that end up on a roadmap. = Status of bugfixing = Two major surprises lately: arabic support and provisions for operating with full NAND. Arabic support includes taking in account RTL in the UI layout, may not land in 8.2.0. Being resilient to NAND full situations is very important in Uruguay, where machines that get full cannot boot until are reflashed. Several options are open here and we are trying to reach consensus. = Introducing the new developers = No new developers :( Maybe next week! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: 1. The datastore 2. OS Updates 3. File Sharing 4. Activity Modification 5. Bitfrost 6. Power management Note that half of these items have nothing to do with Sugar, oo the subject line is a bit misleading. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bert Freudenberg wrote: | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: | | 1. The datastore | 2. OS Updates | 3. File Sharing | 4. Activity Modification | 5. Bitfrost | 6. Power management | | Note that half of these items have nothing to do with Sugar, oo the | subject line is a bit misleading. Every one of them requires work on the Linux-based software stack that runs on the XO. The name of that stack is Sugar, as far as I'm aware. Perhaps a breakdown would be helpful: 1. The datastore: Glucose 2. OS Updates: Ribose. (Ribose is all the low-level software that keeps Sugar running on the XO) 3. File Sharing: Glucose 4. Activity Modification: Glucose and Fructose. 5. Bitfrost: Glucose and Ribose. 6. Power management: Glucose, Ribose, and EC. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI+dwACgkQUJT6e6HFtqROZgCeLfWTvjKraknjHT9MkrkK2Dhe LcEAn2mHnSx0+2uvpEQpkCVOUCii/Zlx =rbFq -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
Ben, I think many people will agree with much of what you have identified in your rant; and we have been working on making the most progress we can given the constraints of the 'real' world: 1 - 350,000 laptops in the hands of kids today. This alone takes most of the resources away from your identified big issues and forces us to focus on the serious bugs that are currently shipping. This is not an excuse... just reality. We identified all the items you have written down as being 'not good enough' pretty much from the day we shipped. But the problems of real world take precedent over the next features. At the same time, we have been hiring so we can try to tackle both: support what we've shipped AND make progress on the next features. Hiring and coming up to speed take many months. 2 - OLPC never had enough resources to deliver all 6 of these new technologies with 'developed world' quality from day 1. This has been identified well before we even shipped the first laptop... and we decided it was still better to have something in the hands of kids rather than nothing. We've heard it from others who have visited schools in Mongolia, Rwanda, Haiti, Uruguay, etc. and I will add my voice to that group as I just got back from visiting a school in Peru. The students and teachers are all learning so quickly with the laptops, and they are all excited and appreciative to have this opportunity in their school. It really is better to continuing shipping these laptops where they can help children, then to stop and 'get it right' for the developed world market. Yes, sometimes progress is slow; and I (for one) appreciate the time and thought you put into this list as it DOES represent the areas where we want to make progress and can most use help. Now, maybe we can turn this list into a real request for how people can help! Kim On Jul 24, 2008, at 2:25 PM, Benjamin M. Schwartz wrote: (Foreword: I originally intended to send this e-mail after the release of 8.2.0, but I have been convinced to send it earlier in order to prompt discussion) Dear OLPC developers, Congratulations on your work so far towards 8.2.0, with its new UI, new underpinnings, and thousands of individual improvements. It took years of effort to get this far, and a tremendous amount has been done to reinvent the entire notion of a software stack to better serve the educational needs of children. This release will be a triumph. Unfortunately, it is also an abysmal failure. There is hardly a worse operating environment available than Sugar as it currently stands. In addition to an amazing variety of terrible bugs, this failure is due to a handful of major missing features. I list here six major missing features, and what can be done about them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding. 1. The datastore Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements. Solution: There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority. 2. OS Updates We now have hundreds of thousands of laptops deployed in the field, running a variety of OS versions. OLPC cannot afford to support a multitude of decrepit versions, and children cannot afford to suffer defects that have long since been fixed. We need a reliable, fast, update system that does not rely on the network, so that children everywhere can move to the latest version of Sugar without losing their data. The update system must support tremendously invasive upgrades, like repartitioning the NAND and replacing JFFS2, because we expect to do this in short order. Solution: A secure usb autoreinstallation stick is required. It is not technically challenging to implement, but it must be made a priority, and then be made widely available and idiot-proof. 3. File Sharing Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer
[sugar] From way out in right field Re: Congratulations! but Sugar sucks
On 平成 20/07/25, at 6:53, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bert Freudenberg wrote: | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: | | 1. The datastore | 2. OS Updates | 3. File Sharing | 4. Activity Modification | 5. Bitfrost | 6. Power management | | Note that half of these items have nothing to do with Sugar, oo the | subject line is a bit misleading. Every one of them requires work on the Linux-based software stack that runs on the XO. The name of that stack is Sugar, as far as I'm aware. Perhaps a breakdown would be helpful: 1. The datastore: Glucose 2. OS Updates: Ribose. (Ribose is all the low-level software that keeps Sugar running on the XO) 3. File Sharing: Glucose 4. Activity Modification: Glucose and Fructose. 5. Bitfrost: Glucose and Ribose. 6. Power management: Glucose, Ribose, and EC. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI+dwACgkQUJT6e6HFtqROZgCeLfWTvjKraknjHT9MkrkK2Dhe LcEAn2mHnSx0+2uvpEQpkCVOUCii/Zlx =rbFq -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar I'm not an active participant anywhere, just someone who wanted to but has never had the time. And I hate to be the party pooper. But, ... The keyword here is bloat. The source of the problem is the Sell. The Sell is Bill Gates's patented (with lots of prior art) checkmate move. When I ran out of time to monitor the list, you guys were still warding off the Sell, but somewhere in the last half-year, you succumbed. The only defense was to let those people that are deceived by Microsoft's sell tactics alone, let them wake up and smell the coffee when they do. That defense was set aside somewhere around the time somebody said, give the user su. Features take storage space, and some features are deceptively simply to spec and impossible to implement. There is no defense now. The only way forward is to go un-sell. Strip out the bloat and send someone around to apologize. Joel Rees ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kimberley Quirk wrote: | I think many people will agree with much of what you have identified | in your rant; and we have been working on making the most progress we | can given the constraints of the 'real' world: Kim: Though I was obviously trying to be a bit provocative with my letter, I did not mean to imply a criticism of the work that has been done so far. ~ I have been very impressed with what you and the Sugar team have been able to accomplish, given the many constraints under which you have been operating. The point of my letter, ideally, is positive. Stated more formally, my thesis is: The list of missing features needed to make Sugar a first-rate system is really surprisingly short. Each item on the list has been debated to a stationary point over the last two years, so all that is left is to make a final decision for the engineers to execute. Each task could be completed or hugely improved by a single developer in a few months, provided that we do not allow changes to the requirements, and the developers are not asked to split their time and focus. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJG8oACgkQUJT6e6HFtqQ3rACeIcRBMnaaCaLuFWjoDogq8PDx AGYAniKBirOfFkA7CycAmHg0ObPcX5OL =peKD -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity names vs. types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Polychronis Ypodimatopoulos wrote: | At any rate, I will add (I filed a ticket) a sufficiently large (255 | chars?) name field for activities, although I would much prefer | designing this mechanism properly (any suggestions by Sugar(ed) | developers?). I last discussed this issue with you at http://wiki.laptop.org/go/On_Presence_updates/User_Profiles/Collaboration. ~ I didn't understand your perspective then, and I still don't understand it now. I don't know what you intend to achieve with Activity Type IDs, why they're so short, or how they will be exposed through Telepathy. However, I can ask a question: Why does the name field have to be some fixed size? Would it not be more efficient and flexible to use delimiters and let the size float? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJWckACgkQUJT6e6HFtqT6nwCfcSAHTKkrFOoSlBnX4wwTJsfY h1gAn0l19BcTCuLqKhjs2R6VYHqHiKUD =k+PK -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity names vs. types
Hi Ben, Benjamin M. Schwartz wrote: I last discussed this issue with you at http://wiki.laptop.org/go/On_Presence_updates/User_Profiles/Collaboration. ~ I didn't understand your perspective then, and I still don't understand it now. Please be more specific on what part of the activity type you don't understand. I thought of it similarly to port numbers, some of which are well known and some are not. Different web servers may be used on port 80, but they all use the HTTP protocol. I understand that you may not agree with the port numbering system altogether and I don't really insist on activity types either. Just an idea. Why does the name field have to be some fixed size? Would it not be more efficient and flexible to use delimiters and let the size float? I was being plainly lazy. I still think there should be a proper design, potentially from scratch, of the activity sharing mechanism, as I am not satisfied neither with cerebro's implementation, nor with telepathy's. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
On Thu, Jul 24, 2008 at 8:18 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: really surprisingly short. Each item on the list has been debated to a stationary point over the last two years, so all that is left is to make a final decision for the engineers to execute. Each task could be completed or hugely improved by a single developer in a few months, provided that we do not allow changes to the requirements, and the developers are not asked to split their time and focus. I do not believe that either of these statements is correct. We are not lacking in decisions: we have substantially complete designs; we are lacking implementation. Each of your items is not the work of a single developer in a few months: solving these problems is realistically a year's work at least, if we have a single developer working full time on each. And honestly, OLPC does not actually have the resources to devote a even single unique developer to each. If they did, we would not have any releases made, languages added, deployment issues addressed, emails sent to devel@, additional engineers interviewed and hired, or any of the myriad other tasks which the overstretched OLPC engineers currently do. We need realistic management and expectations, and I'm afraid that, so let's just do these things isn't going to help us much. But in one fundamental way you are entirely correct: these are (some of) our goals for our platform, and we should ensure that we are making progress in each release toward these ends. We should ensure that *some* progress is made in each of these areas in 9.1, and *some more* progress in 9.2, and so on until the features are complete. If we allow the work to be arbitrarily deferred, we will never get any closer to where we want to be. --scott ps. and, of course, you've neglected software for kids that does things kids want to do, powerful and pervasive collaboration and mesh networking in your list of items. -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
