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] 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
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] Remarks on the Work of Sugar
Mikus Grinbergs wrote:
Been bothered by the seeming approach found too often in Sugar --
To set things 'right', re-start Sugar. {like with windows!}
Do you mean when you change settings in the control panel? We hope to do a
better
job for the next release so that you can change preferences on the fly.
Best,
Simon
PS: your email has a Re: in the title but I can not find any other previous
emails
with the subject, which ones are they?
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Simon Schampijer wrote:
Mikus Grinbergs wrote:
Been bothered by the seeming approach found too often in Sugar --
To set things 'right', re-start Sugar. {like with windows!}
Do you mean when you change settings in the control panel? We hope to do a
better
job for the next release so that you can change preferences on the fly.
Best,
Simon
PS: your email has a Re: in the title but I can not find any other previous
emails
with the subject, which ones are they?
Sorry found it now, my bad.
Simon
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Marco Pesenti Gritti wrote: On Wed, Jul 23, 2008 at 3:14 AM, Martin Langhoff [EMAIL PROTECTED] wrote: Michael's analysis is useful inasmuch we can read it going forward. As Michael, I wasn't here 2 years ago, but I have been on the ground on many projects under tight deadlines. It's not helpful to pontificate on the decisions I may have made in them. Hindsight is always 20/20. So let's focus on the bits of Michael's notes that can be transformed into praxis going forward -- and let's be thankful that none of the under-pressure decisions have really painted us into a corner (of the rewrite kind). Revisionism will have to wait till I get that time-travel machine project finished. Sure. The thing is that I'm unconvinced that we can really say that the under-pressure phase is over. More specifically. Can we declare the end of UI experimentation and redesign? Can we start pushing back on features until we are ready to implement them properly? Can we devote the next release cycle to bug fixing, polishing and performance improvements? My opinion is that we should do it, but I don't have the feeling that we have consensus about it. Marco Since we were busy prototyping a mass production user interface we had nearly no time to do performance work - which is really sad. Same is true for documentation and welcoming contributors. I really would love to focus on performance work and friends next release cycle - that would go a long way and would in my opinion be the best feature ever. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Michael Stone wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. Write, Read, TamTam, Paint, Record, Memorize to name a few have been really struggling lately. There are probably various reasons for that - one might be I that the activities have been taken out from the base system another one that the overall development has been really fast and no entry points/good documentation could be found. And well, the windows news were not helpful either. Would be interesting to know what the activity maintainers struggled most to make it easier in the future. For sugar core - I don't think that 'small fixes' need more than python skills. And we would be more than happy to have them. We will try in the next sugar dev meeting s to give out a few bugs that we think are easy to work on where people could help - stay tuned. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 9:36 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Michael Stone wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. One hint from Robert about how the project is seen by FOSS people: Jul 19 15:43:38 tomeu Robot101: thanks for remembering the gnome mobile people that we are still alive Jul 19 15:43:57 tomeu would have been great to be at guadec :/ Jul 19 15:44:47 Robot101 yeah they were somehow talking about OLPC as dead and failed, I had to give them some re-schooling Would you spend much time on a dead and failed project? Note that the GNOME Mobile people are not supposed to be the kind of people that know about OLPC only from NBC News. About the rest, Michael's post makes me think he believes that we are very proud of our work. Just for the record, I think my work at OLPC is crap and I would have refused to deliver so poor quality in any commercial project (in case any future employer is reading this.) I have kept going on with this craziness because I expected that at some point the promises of more resources would be fulfilled. If our only plan is to blame the Sugar developers for not being able to attract more developers for free... It may not be worth the effort. Best regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 7:56 AM, Michael Stone [EMAIL PROTECTED] wrote: [2]: I consider web-browsers and Unix shells to be fluent translators for the programmers who I expect to be hacking on Sugar as opposed to the dbus-introspection tools which currently seem to me to be like novice translators. To be honest I feel like this is the weaker of the points you raised. There is whole a software ecosystem out there which uses DBus. And as far as I know it's not being a stopper for contributions, all the opposite actually. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 6:56 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: On the other hand, circumventing the layers altogether has not been an option either as it would brake backwards compatibility with existing activities (Sugar is a two-year old experimental project and already has legacy?). The fact that this prototype is already heavily deployed puts us in a very difficult situation in this respect. We will have to figure out ways to break compatibility but it's going to hurt :/ Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: Michael Stone wrote: [...] Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. [...] For sugar core - I don't think that 'small fixes' need more than python skills. I agree. Of course people also need the knowledge about where to put those python skills to work. That's non-trivial in Sugar, but - apart from m_stone's layering comment - I don't think the UI-code makes this more of a problem than it just is, inherently. Best, Simon Martin pgpbxDe2lPOqw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Martin Dengler wrote: On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: Michael Stone wrote: [...] Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. [...] For sugar core - I don't think that 'small fixes' need more than python skills. I agree. Of course people also need the knowledge about where to put those python skills to work. That's non-trivial in Sugar, but - apart from m_stone's layering comment - I don't think the UI-code makes this more of a problem than it just is, inherently. Best, Simon Martin Sure, some guidance is needed. I hope we have done a decent job to guide you to the places to provide your great fixes :) for example: http://dev.laptop.org/git?p=sugar;a=commit;h=40306308325448fe85c2a78ad243aa179fd1b37f http://dev.laptop.org/git?p=sugar;a=commit;h=8127e2680e101b36218b4576733a4d69537e5915 Thanks! Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 11:33:38AM +0200, Simon Schampijer wrote: Martin Dengler wrote: On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: For sugar core - I don't think that 'small fixes' need more than python skills. I agree. Of course people also need the knowledge about where to put those python skills to work. [...] Sure, some guidance is needed. I hope we have done a decent job to guide you to the places to provide your great fixes :) Yes, you (plural) have! Thanks! I didn't mean to imply otherwise. Thanks! Simon Martin pgpAL47xubyVs.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, 2008-07-23 at 09:36 +0200, Simon Schampijer wrote: Write, Read, TamTam, Paint, Record, Memorize to name a few have been really struggling lately. There are probably various reasons for that - one might be I that the activities have been taken out from the base system another one that the overall development has been really fast and no entry points/good documentation could be found. And well, the windows news were not helpful either. You are missing 'funding': Most of Write's development was funded by OLPC, which gave us what we have today. Expecting volunteers to hack on Write is unrealistic at this point. Let me clarify: Write is written in Python and uses the pyabiword bindings around AbiWord's GTK canvas widget extensively. The GTK widget and pyabiword bindings were extended as I went along, to expose the functionality Write needed. Currently almost 100% of pyabiword's functionality is used by Write. What this means is that if Write needs new feature X, it will almost always require new functionality to be exposed through pyabiword *and* AbiWord's GTK canvas widget. This will generally be too hard for volunteers who just want to spend a few hours hacking on something fun. Cheers, Marc ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
[This does not fit the 'Subject:', but is still worth remarking.] Walter wrote: It is clear from even a casual review of the devel and sugar lists and trac that much of the frustration experienced by both users and developers resides not in the details of, for example, dbus or Python, but rather in more catastrophic and unpredictable failures of the network ... My comment arises out of my dissatisfaction with the use of the network lights on the front panel of the OLPC. My problem is that although how the OLPC communicates has been written about, I have been UNABLE to form a clear picture of how 'destinations' interact. [The current use of the lights is confusing and uninformative. I think a light being off should show the corresponding connectivity does not exist. Flashing could show that connectivity is being (re)attempted; and pulsing could show this connectivity is being actively used at this moment.] I can identify five different 'destinations' for OLPC communication: (1) To another XO, via the mesh (under the tree) (2) To the school server, via the mesh [e.g., no AP relay] (3) To another user (XO?), via an AP relay [today - via jabber] (4) To the school server, via an AP relay (5) To a (non-school) server on the internet, via an AP [wget] It is difficult to intelligently map the states of these five modes onto just two lights (all that are available on the XO-1). What from the lights information will best guide the behavior of the kid using the XO? I think it makes a difference to the kid's future behavior if he is connected to the internet or not -- that makes showing AP status a good candidate for a front panel light. I also think the kid would like to see at a glance whether he can at this instant fetch_from/save_to the school server -- in my opinion showing school server status is a good candidate for using a front panel light. Then, for instance in under the tree situations, the kid wants to know whether he can communicate with his buddy. Right now it involves an explicit invocation of Neighborhood View to check on that -- a good use for a THIRD light would be to show mesh status. [With only two lights available, perhaps a Control Panel function could assign what those lights show, Then G1G1 users would likely not ask to see the school server status.] And clearly written DOCUMENTATION would be helpful -- particularly a guide for connecting to 'destinations. For instance, HOW does switching communication to the school server between mesh-IP-address access and AP access (presumably with an internet-IP-address) work ? And if buddies were formerly accessed through the mesh, but starting at 1 p.m. are to be accessed through the school server jabbber - what needs to happen at the XO (does the kid have to do anything) ? mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
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? = 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? But the tools needed to be a contributing part of the Sugar community don't run on the XO. There is no introductory material about how to hack on Sugar on your XO. There isn't an ASCII text editor other than vi, and no documentation on it. The concepts of file names and directories, in which the Python source files are kept, and which must be scrupulously adhered to to modify them successfully, is foreign to the user interface, which throws everything into an unstructured heap. There's no email. There's no source code control system. Kids could manually create diffs, if they remembered to save the pre-change files, but they won't. There's no website where they can upload changes into the Sugar team's deliberations. Distributing their draft changes among their local XO peers for testing and collaboration would be another exercise in frustration; ssh/scp doesn't work, they have no USB memory sticks, they can't build RPMs; you can't just share a file, you have to share an activity, ... The recipient of a patch (what's a patch? We don't ship diff or patch) or a changed file would need to know almost as much as the author. Merely installing the change without trashing his XO's entire GUI with a typo or missing Python file is tricky. I was shocked(*) when after Christmas, a user posted a one-line patch that disabled the Frame for people whose touchpads flee crazily into the corners of the screen. It was, like, you can just edit this file on your laptop and this bug goes away? But that was a single shot in the dark. I haven't seen a similarly produced patch since. (Though in Joyride a control panel option now handles that particular touchpad/frame misfeature.) There IS pippy, so the kids can learn Python syntax and semantics, instead of just turtle programs and gooey smalltalk. Yay! But they'll need a lot more help to apply that knowledge to Sugar itself. 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. In many ways the unique XO UI and collab setup make the learning curve steeper, not easier. John (*) I'm a professional programmer and I know such things are possible. The shock was because it was just dis guy posting brief instructions that anyone could follow in 2 minutes -- rather than a Sugar insider, building a custom RPM or .XO on some big server somewhere in a data center, and rolling it into a distribution that'd wipe out all your data when you install it. Sugar is hung up in its own maintenance machinery. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Remarks on the Work of Sugar
After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. 2) Sugar would run more smoothly on-XO if jhbuild were retired. By running at non-XO speeds, jhbuild permits Sugar developers to retain faulty assumptions about the environment in which their code will run. Evidence: Sugar uses algorithms which casual inspection reveals to be horribly slow and Sugar has, in the past, suffered from easily-revealed memory leaks which went unfixed for long periods of time in part because developers had little personal motivation to fix the issues. 3) Sugar is built on technologies which encourage excessive layering. Excessive layering makes it hard to approach code (high cognitive burden) and harms performance (by causing unnecessary data copying and by causing data to be stored in the heap rather than the stack or in pageable regions of memory. Evidence: the convenience layers of Python wrappers around dbus-python stubs around dbus objects around two layers of python bindings for an information retrieval system built on a filesystem in merely to create and save files with a dict of attached metadata. Evidence: The convenience layers of Python wrappers around gobject properties around dbus-python stubs around dbus objects around a hardcoded network manager around the underlying CLI tools and the kernel's netlink sockets. Evidence: The SVG python icon objects in a three-layer Sugar icon cache spanning gobject properties and cairo surfaces atop gtk and gdk windows atop X windows and pixmaps atop... 4) Sugar's underlying technologies bias it toward computing results more eagerly than is appropriate. Evidence: Python and C are eager languages without well-documented support for lazy computation. Evidence: Sugar performance has been shown to improve by making some computations lazy, e.g. palette creation. 5) Sugar is built on technologies that incentivize its developers to recompute prior results which could be cached across boots. Evidence: Sugar is developed by people running on hardware that is fast enough to recompute results at little cost to interactivity (see §2). Evidence: Also, OLPC's shipping JFFS2 implementation does not support writable mmaps or uncompressed inodes. Evidence: Python lacks support for loading data without unmarshalling it from bytestreams. 6) Sugar was not built with compartmentalization in mind. All its functionality runs with the full privilege of the human operator and it has very coarse process-level memory protection. Evidence: Sugar packs great functionality into a small number of processes and occupies only one uid. Evidence: Sugar's process-level boundaries (e.g. shell, DS, PS, telepathy CMs, rainbow, activities) seem to me to be strongly correlated with the existence of cliques of the developers who built them. 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). Regards, Michael P.S. - Let me know if you'd like to see more such remarks in the future (perhaps on other subsystems?) or if you'd like to see more detailed exploration of any of the items noted above. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Jul 22, 2008, at 7:49 PM, Michael Stone wrote: Python lacks support for loading data without unmarshalling it from bytestreams. Can you clarify what specifically you mean with this point? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Apologies for the immediate self-reply, but Marco pointed out to me that I left out one important piece of context: All of the issues I raise above were selected, in part, because I believe that they are incrementally fixable. Some require adjustments to underlying technologies, some require changes in mindset, etc, but all can be attacked today. Ask for details if you want them, or better, try to supply your own. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Tue, Jul 22, 2008 at 08:01:02PM -0400, Ivan Krstić wrote: On Jul 22, 2008, at 7:49 PM, Michael Stone wrote: Python lacks support for loading data without unmarshalling it from bytestreams. Can you clarify what specifically you mean with this point? I regard fully pythonic python data as a subgraph of a reference-counted object graph. So far as I know, Python has lots of interesting ways to parse bytestreams into object graphs, but no great way to read an object graph directly into memory without the overhead of parsing or to save an subgraph of its object graph directly to a bytestream. This makes it hard to use pythonic data via shared-memory or to pull it quickly off of a filesystem. (An interesting potential hack would be to teach Python how to use multiple object graphs so that one could more easily confine an interesting subgraph to a fixed set of pages.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 11:49 AM, Michael Stone [EMAIL PROTECTED] wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. Excellent analysis. +1 on it, and a couple of minor notes... Aspects of #1 and #6, specifically: 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. vs 6) Sugar was not built with compartmentalization in mind. All its functionality runs with the full privilege of the human operator and it has very coarse process-level memory protection. ... Evidence: Sugar's process-level boundaries (e.g. shell, DS, PS, telepathy CMs, rainbow, activities) seem to me to be strongly correlated with the existence of cliques of the developers who built them. Modularity and security compartamentalisation go hand in hand, and are a social aspect of software. If we have more of what you want in #1, we will see more of #6. 3) Sugar is built on technologies which encourage excessive layering. +10. 5) Sugar is built on technologies that incentivize its developers to recompute prior results which could be cached across boots. ... Evidence: Also, OLPC's shipping JFFS2 implementation does not support writable mmaps or uncompressed inodes. Missing writable mmaps is a real problem - lots of applications are just not possible to accomplish with adequate performance without it. Evidence: Python lacks support for loading data without unmarshalling it from bytestreams. The way you've written this strikes me as overbroad, but I think you've answered that elsewhere. Unmarshalling costs around IPC do seem to be significant for the bits of code I've looked at. IME, IPC is fantastic to deliver tiny bits of data that says hey, here's the real thing with a file path, shmem address or similar . 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). I wouldn't encourage http :-) cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | 5) Sugar is built on technologies that incentivize its developers to | recompute prior results which could be cached across boots. Sugar was intended to write to disk absolutely as little as possible, and also to reboot as infrequently as possible. I will attempt to find references to these intentions from years ago. Regarding the majority of your points, I would say: Sugar has been, and continues to be, in a constant rush just to implement the desired functionality, regardless of efficiency. The question has long been how can we code this as fast as possible, not what is the ideal way to implement this. I think that is a good thing. I think we will need retain this mindset through 9.1, in order to finally deliver a Sugar that has the features required for usability. I hope that Sugar developers can spend 2009 focusing on efficiency, laziness/memoization/eagerness, and delayering. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiGe9wACgkQUJT6e6HFtqRQlgCcD5u0UXpqr+tR5Yf7aeSFd6yy QHQAoJ72ZXy7+PCVF66av7BsMahd+VNz =IsWm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 12:19 PM, Michael Stone [EMAIL PROTECTED] wrote: I regard fully pythonic python data as a subgraph of a reference-counted object graph. So far as I know, Python has lots of interesting ways to parse bytestreams into object graphs, but no great way to read an object graph directly into memory without the overhead of parsing or to save an subgraph of its object graph directly to a bytestream. This makes it hard to use pythonic data via shared-memory or to pull it quickly off of a filesystem. None of the dynamic languages I am used to can do this - Perl, Python, PHP, Ruby - even with locks or read-only shmem arrangements. Whenever I've used a shmem arrangement in any of them, it involved marshalling/unmarshalling, which of course is a huge perf drag. Which makes me suspect that there's something else that is tricky there -- things in that shmem space do have references to the private mem of the originating process (pointers to the class code perhaps). I understand the PHP and Perl (circa P5.0005) internal memory handling. YMMV. In other words, it's in the way-too-hard-and-brittle basket, barring an execution-engine redesign, that might incorporate some changes. OTOH, ISTR reading that Erlang's odd all-variables-are-constants scheme makes this easier. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 1:49 AM, Michael Stone [EMAIL PROTECTED] wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. We are moving in that direction already. Even the home view layout you mention has been recently refactored to be easily replaced. 2) Sugar would run more smoothly on-XO if jhbuild were retired. By running at non-XO speeds, jhbuild permits Sugar developers to retain faulty assumptions about the environment in which their code will run. Evidence: Sugar uses algorithms which casual inspection reveals to be horribly slow and Sugar has, in the past, suffered from easily-revealed memory leaks which went unfixed for long periods of time in part because developers had little personal motivation to fix the issues. The memory leaks thing is not true. We started to work on them as soon as they was reported. Unfortunately the pygtk bindings leaks very easily. I agree that we should do more testing and dogfooding on the XO, but I don't see why should prevent people to hack on Sugar outside the XO. All our changes goes in joyride very regularly and get tested. A little automated testing would go a much longer way than getting rid of jhbuild in this area, ihmo. 3) Sugar is built on technologies which encourage excessive layering. Excessive layering makes it hard to approach code (high cognitive burden) and harms performance (by causing unnecessary data copying and by causing data to be stored in the heap rather than the stack or in pageable regions of memory. Evidence: the convenience layers of Python wrappers around dbus-python stubs around dbus objects around two layers of python bindings for an information retrieval system built on a filesystem in merely to create and save files with a dict of attached metadata. Evidence: The convenience layers of Python wrappers around gobject properties around dbus-python stubs around dbus objects around a hardcoded network manager around the underlying CLI tools and the kernel's netlink sockets. True. But as Benjamin points out there is a trade off between adding new features quickly and implement them in the most efficient way. This is something that we will have to improve radically. I've been frustrated about the various level of wrappers around the dbus calls for a while now, but we are not going to be able to address them until we are required to add features. Evidence: The SVG python icon objects in a three-layer Sugar icon cache spanning gobject properties and cairo surfaces atop gtk and gdk windows atop X windows and pixmaps atop... Leaving aside the cache issue, that's the normal implementation of a gtk widget in python, you'd have to switch language or toolkit to drop layers. 5) Sugar is built on technologies that incentivize its developers to recompute prior results which could be cached across boots. Evidence: Sugar is developed by people running on hardware that is fast enough to recompute results at little cost to interactivity (see §2). Evidence: Also, OLPC's shipping JFFS2 implementation does not support writable mmaps or uncompressed inodes. Evidence: Python lacks support for loading data without unmarshalling it from bytestreams. Sure. But again, there is the features/quality tradeoff to consider. 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). The heavy use of DBus derive partially from the platform we are using (GNOME/Freedekstop). The trend there is to increase it's usage and I don't see how it could not affect us in the future. Anyway, I agree that in some cases we abused DBus, and the reason is simply that it was so damn easy. Back to the usual tradeoff... This is something that will be incrementally addressed. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 2:46 AM, Michael Stone [EMAIL PROTECTED] wrote: I disagree because I think that the approach we have taken has made it much harder for others to help us. For a project like Sugar, this ultimately results is less software of less quality in the same timeframe. At least, that's what I take away from the Trac and xmonad examples. (When you examine your own notoriously easy-to-contribute-to projects, do your conclusions match mine?) That's a tradeoff and a very difficult one. In retrospect I tend to think we invested too little on enabling contributions. But you should consider a few of things: * Sugar is very much of an experimental project at the UI level. It's making big progresses on that front but even now it's far from solid. To be able to iterate on UI design you need quick prototyping. And to be fair, in so many respects, Sugar is still a prototype and will be for a long time. * Deployments are putting a huge pressure on us. We can't just delay features to do them right, often we are just forced to hack them up at the best we can. * The disproportion between the project expectations and the bootstrap investment is simply ridiculous. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Michael's report resonates with me perfectly. I 'm trying to contribute to a rather core part of Sugar, its collaboration system, but I can't because the time required to master and use the various layers I need to work with has been prohibitive. On the other hand, circumventing the layers altogether has not been an option either as it would brake backwards compatibility with existing activities (Sugar is a two-year old experimental project and already has legacy?). I have been working with the XO ever since the A-Test boards and I am not familiar with any significant contribution to the collaboration system by volunteers so far. On the other side, Ben's and Eben's points are completely valid: the time frames vs. resources available between releases have been ridiculously disproportional. On another note, should we look into Google's protobufs (http://code.google.com/p/protobuf/) to be used as structures to be passed in inter-process calls? These are essentially compiled data structures, but I'm not sure if the trade-off for (de)serializing data is worth it, even if native code is used to perform the action. As an alternative to Michael's suggestion for IPC mechanisms, I think the problem is not the mechanism itself, but rather the data we are passing using the mechanism. Like Martin said, Dbus works great for small messages, but passing whole objects renders the whole mechanism counter-intuitive. What happened to good-old JSON? JSON maps exactly onto Python dictionaries (un)marshaling data is as simple as str() and dict(). Pol Michael Stone wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. 2) Sugar would run more smoothly on-XO if jhbuild were retired. By running at non-XO speeds, jhbuild permits Sugar developers to retain faulty assumptions about the environment in which their code will run. Evidence: Sugar uses algorithms which casual inspection reveals to be horribly slow and Sugar has, in the past, suffered from easily-revealed memory leaks which went unfixed for long periods of time in part because developers had little personal motivation to fix the issues. 3) Sugar is built on technologies which encourage excessive layering. Excessive layering makes it hard to approach code (high cognitive burden) and harms performance (by causing unnecessary data copying and by causing data to be stored in the heap rather than the stack or in pageable regions of memory. Evidence: the convenience layers of Python wrappers around dbus-python stubs around dbus objects around two layers of python bindings for an information retrieval system built on a filesystem in merely to create and save files with a dict of attached metadata. Evidence: The convenience layers of Python wrappers around gobject properties around dbus-python stubs around dbus objects around a hardcoded network manager around the underlying CLI tools and the kernel's netlink sockets. Evidence: The SVG python icon objects in a three-layer Sugar icon cache spanning gobject properties and cairo surfaces atop gtk and gdk windows atop X windows and pixmaps atop... 4) Sugar's underlying technologies bias it toward computing results more eagerly than is appropriate. Evidence: Python and C are eager languages without well-documented support for lazy computation. Evidence: Sugar performance has been shown to improve by making some computations lazy, e.g. palette creation. 5) Sugar is built on technologies that incentivize its developers to recompute prior results which could be cached across boots. Evidence: Sugar is developed by people running on hardware that is fast enough to recompute results at little cost to interactivity (see §2). Evidence: Also, OLPC's shipping JFFS2 implementation does not support writable mmaps or uncompressed inodes. Evidence: Python lacks support for loading data without unmarshalling it from bytestreams. 6) Sugar was not built with compartmentalization in mind. All its functionality runs with the full privilege of the human operator and it has very coarse
