Re: Congratulations! but Sugar sucks
Let me try to prioritize this list, from what I've experienced in the field (Haïti): Benjamin M. Schwartz [EMAIL PROTECTED] writes: 1. The datastore 2. OS Updates 3. File Sharing 4. Activity Modification 5. Bitfrost 6. Power management I'd reorder this into: 1. Power management 2. OS Updates 3. The datastore 4. File Sharing 5. Bitfrost 6. Activity Modification -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
Am 24.07.2008 um 17:53 schrieb Benjamin M. Schwartz: 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. I don't think that taxonomy actually has caught on. Commonly, only the fructose and glucose layers are referred to as Sugar (as for example discussed on the Sugar list) - basically, the UI and parts it directly depends on (datastore, presence). This is the stuff most directly impacting the learning experience, whereas bitfrost, power management, and OS updates are both of more general use (e.g., I'd love to see bitfrost-like security in my desktop, too) and not directly visible to the learner. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Congratulations! but Sugar sucks
| 1. The datastore | 2. OS Updates | 3. File Sharing | 4. Activity Modification | 5. Bitfrost | 6. Power management On Thu, Jul 24, 2008 at 11:02 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: 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. I have experience with numbers 1, 3, and 5, and am the principal person responsible for 4 right now. I would say that 3 and 4 are definitely within the single dev in a few months time frame; depending on the definition, 4 is in the as soon as currently applied patches percolate into production time frame. The further work on 4 - already started - is in the area of activity signatures, which is actually encroaching on 5. In a few full-time months of a single developer, this would put 4 at a place which other platforms could envy, and make concrete strides towards 5, to the point where security would be better, not worse, than other modern platforms (though I agree that there is plenty more work to fulfill the true promise of Bitfrost). I agree that 1 is not so simple; while a rockstar developer might be able to solve all our problems in a two-month all-nighter, 6 months to a year is a more realistic timeframe to get something really solid and stable. What I have accomplished - admittedly too slowly - on Develop, I have done in under half-time commitment. I have made it pretty clear that I was available for full-time work, pretty cheaply, but not for free. I could work to contract, with payment working out to around what the GSoC students are getting, and have Develop and Bitfrost in a significantly better place by the end of September (activity signatures done, bitfrost privileges by-application secure on that basis, the Terminal/Journal bitfrost loophole mendedl; Develop collaboration/source control starting to be usable). 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. All of which are slightly less sucky in their current state than the items mentioned, I think, but definitely need work too. To sum up: if this is a matter of resources, just hire people. Me, and others who want it - I have heard marcopg complaining that he should be full-time, I think. In my case, the worst that could happen is that I don't come through, and, since I am asking for contract work, that would mean you don't pay me, so it would be identical to current situation. The best would be that for less than the price of a classroom-full of XOs, you would get large steps on two of these list items in a couple of months. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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: 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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 - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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
From way out in right field Re: [sugar] 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 [EMAIL PROTECTED] 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
On Fri, Jul 25, 2008 at 12:18 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: The list of missing features needed to make Sugar a first-rate system is really surprisingly short. Fantastic news! As Kim points out, we knew most (all?) those things already, and we are just extremely short on *people* so if you want to make a difference, trade the provocative letter-writing for some testing patching help. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
