Re: [Sugar-devel] Location of Saved XO Settings
On Tue, Feb 24, 2009 at 01:17, Eduardo H. Silva wrote: > yep, once again I am wrong :) sensible options should be added to the > control-panel. Perhaps it could exist as a separate activity, a > power-user tool like the Terminal, Analize and Log activities are. Perhaps gconf-editor can just be run from the terminal? Seems to work pretty well here. Regards, Tomeu > Eduardo > > 2009/2/23 Luke Faraone : >> On 2/23/09, Eduardo H. Silva wrote: >>> This gconf-editor tool should be accessible somewhere in Sugar (the >>> control panel?): remember, low floor, high ceiling. >>> >> >> The main concern with making these keys easilly accessible are >> twofold: it discourages from implementing the settings in a >> user-friendly panel applet (see firefox's about:config or the windows >> registry) and secondly it makes it simpler for a child to hose their >> setup. Gconf-edit is not meant to be a user-facing tool, but a last >> resort when normal configuration tools provided by an app are >> insufficent. >> >> For this reason, I think adding the editor to the control panel would >> be a mistake. >>> >> >> >> -- >> Luke Faraone >> http://luke.faraone.cc >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS - moving onward...
Sebastian Dziallas wrote: > Hi all, > > and here's another announcement for Sugar on a Stick! > > You can grab your updated version now directly from here: > > http://download.sugarlabs.org/soas/snapshots/1/latest.iso How does the link gets created. It got killed when syncing with the last image - since it did not exist in the source repository. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Permissions to upload honey sources
On Tue, Feb 24, 2009 at 06:34, Gary C Martin wrote: > Hi folks, > > Just got a shell account on sunjammer (thanks Bernie!), and was hoping > to upload the source of Moon-9 so that it appears in the (as I > understand) official place for distros to go looking for honey: > > http://download.sugarlabs.org/sources/honey/ > > Now... the below wiki page lists /pub/sugarlabs/sources/honey as the > pace to make a directory and upload to: > > http://sugarlabs.org/go/DevelopmentTeam/Activities_packaging > > ... but /pub/sugarlabs/sources/honey doesn't seem to exist on > sunjammer, though I did find /upload/sources/honey/ which seems to be > the correct path as it has the other 4 listed honey sources living > there (/var/www/sugarlabs/download/sources/honey/ is also another > possibility). > > Unfortunately I don't seem to have permission to create a directory > there. /upload/sources/honey is owned by marcopg, group sugarlabs; the > other 4 directories in there were created by alsroot, group sugarlabs. Created a Moon directory. I don't know if activity authors should be in the sugarlabs or not, sorry :/ > I'm guessing on the face of it I'd need to be in the sugarlabs group, > **but** this doesn't seem like a good situation given that honey is > for "activity sources developed out there in the wild", that could > turn into a whole stinging bee hive of admin and excessive shell > access... > > Any (scalable) hints much appreciated! A scalable way would be to use activities.sugarlabs.org for that. I'm not sure what's the current thinking in Mozilla and distros about packaging addons in distros, but if there's any chance they want to support source tarballs, we'll get that support for free. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Location of Saved XO Settings
On Tue, Feb 24, 2009 at 3:07 AM, Tomeu Vizoso wrote: > On Tue, Feb 24, 2009 at 01:17, Eduardo H. Silva > wrote: > > yep, once again I am wrong :) sensible options should be added to the > > control-panel. Perhaps it could exist as a separate activity, a > > power-user tool like the Terminal, Analize and Log activities are. > Perhaps gconf-editor can just be run from the terminal? Seems to work > pretty well here. +1. No need for a separate activity wrapper. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sucrose 0.83.6 in Soas
Hi, Sucrose 0.83.6 - the 0.84 Release Candidate 2 has find it's way into Sugar on a Stick. Get the latest image at: http://download.sugarlabs.org/soas/snapshots/1/Soas-200902231225.iso Have fun, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sucrose 0.83.6 in Soas
On Tue, Feb 24, 2009 at 15:13, Simon Schampijer wrote: > Hi, > > Sucrose 0.83.6 - the 0.84 Release Candidate 2 has find it's way into > Sugar on a Stick. > > Get the latest image at: > > http://download.sugarlabs.org/soas/snapshots/1/Soas-200902231225.iso Does it work in XOs? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sucrose 0.83.6 in Soas
Tomeu Vizoso wrote: > On Tue, Feb 24, 2009 at 15:13, Simon Schampijer wrote: >> Hi, >> >> Sucrose 0.83.6 - the 0.84 Release Candidate 2 has find it's way into >> Sugar on a Stick. >> >> Get the latest image at: >> >> http://download.sugarlabs.org/soas/snapshots/1/Soas-200902231225.iso > > Does it work in XOs? > > Regards, > > Tomeu No, we have a kernel issue (Bernie has pinged the right people) that needs to be fixed first to be able to build XO images. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Permissions to upload honey sources
Tomeu Vizoso wrote: >> Unfortunately I don't seem to have permission to create a directory >> there. /upload/sources/honey is owned by marcopg, group sugarlabs; the >> other 4 directories in there were created by alsroot, group sugarlabs. > > Created a Moon directory. I don't know if activity authors should be > in the sugarlabs or not, sorry :/ Those files should have been owned by group sugardl, not sugarlabs. Fixed. >> Any (scalable) hints much appreciated! > > A scalable way would be to use activities.sugarlabs.org for that. I'm > not sure what's the current thinking in Mozilla and distros about > packaging addons in distros, but if there's any chance they want to > support source tarballs, we'll get that support for free. Indeed! -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Permissions to upload honey sources
On 24 Feb 2009, at 14:44, Bernie Innocenti wrote: > Tomeu Vizoso wrote: >>> Unfortunately I don't seem to have permission to create a directory >>> there. /upload/sources/honey is owned by marcopg, group sugarlabs; >>> the >>> other 4 directories in there were created by alsroot, group >>> sugarlabs. >> >> Created a Moon directory. I don't know if activity authors should be >> in the sugarlabs or not, sorry :/ > > Those files should have been owned by group sugardl, not sugarlabs. > Fixed. Thanks Bernie, looks good from here. --Gary >>> Any (scalable) hints much appreciated! >> >> A scalable way would be to use activities.sugarlabs.org for that. I'm >> not sure what's the current thinking in Mozilla and distros about >> packaging addons in distros, but if there's any chance they want to >> support source tarballs, we'll get that support for free. > > Indeed! > > -- > // Bernie Innocenti - http://www.codewiz.org/ > \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ActivityTeam meeting
On Tue, Feb 24, 2009 at 04:39, Wade Brainerd wrote: > Hi all, > We are holding our second ActivityTeam meeting this Friday at 12pm EST > (17:00 UTC). It should last 1 hour (the length of my lunch break). > Hope to see you there! > What: Activity Team meeting > When: 27 February 2009, 12:00 pm EST > Where: irc.freenode.net, #sugar-meeting > > Agenda: > * Catch up on the past month's progress > * activities.sugarlabs.org discussion Hi, I'm not sure if I will be able to make this meeting, but I would like to suggest some issues related to a.sl.o: ** Identify major issues that block usage by all activity maintainers and/or consumers. ** Make a clear howto about uploading a bundle, nominating it, etc. Could be a guide with screenshots or a screencast, etc (I think that David Farning is looking at this) ** Set up a team of administrators and a team of editors. I guess a couple of people in each could be a good start. Regards, Tomeu > * Status of activity migration + author outreach > * Review of the TODO list > * Distribution discussion > ** Minimum resolution supported by Sugar > ** Help system > * News from this Tuesday's OLPC Deployment meeting. > Best, > Wade > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups "to the masses". ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular "desktops" (I'm sometimes using vnc running under different UIDs for the same purpose). What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael Stone wrote: > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. Now that Sugar was made more modular, I think it's up to the individual distributors to make a choice. It might be enabled by default on XOOS, disabled by default on F11, and so on. > Now, it could certainly be the case that there's more work that I need to do > in > the form of documenting, testing, or pushing my recent rainbows before people > will be excited about trying them out and, if that's the case, someone should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. Is there any work that needs to be done Sugar side in order to adapt it to your refactored version of Rainbow? If so, I'm afraid that: 1) nobody but you understands Rainbow well enough to come up with a proper patch 2) it might be too late for the 0.84 release cycle at this point. > P.S. - I find this state of affairs particularly sad, since I think there's an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". I'm with you on this. Actually, Rainbow is the only part of OLPC's security I find actually beneficial for the user. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ActivityTeam meeting
On Tue, Feb 24, 2009 at 10:41 AM, Tomeu Vizoso wrote: > ** Identify major issues that block usage by all activity maintainers > and/or consumers. > > ** Make a clear howto about uploading a bundle, nominating it, etc. > Could be a guide with screenshots or a screencast, etc (I think that > David Farning is looking at this) > > ** Set up a team of administrators and a team of editors. I guess a > couple of people in each could be a good start. Thanks Tomeu, I added these to the agenda. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form "This can be implemented" and "I believe but have not confirmed" which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: "All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable." Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean "Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: > >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care > about > by simplifying it, by making it more generically useful, by writing some > basic > .deb and .rpm packaging in order to ease testing, and by writing Sugar > patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > > > http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have received no > feedback more serious than a (kind) thank-you note from Walter, let alone > testing, bug reports, or patches. As you might imagine, this overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I need to > do in > the form of documenting, testing, or pushing my recent rainbows before > people > will be excited about trying them out and, if that's the case, someone > should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I think there's > an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, when several weeks ago you showed me in #sugar your patches to Sugar and explained the new rainbow concept, I told you that it seemed a good idea and that the patches looked pretty good. As you said Rainbow wasn't ready for 0.84, I told you that we would talk again when work on 0.86 starts. Which it hasn't yet, afaik. So I don't think you should feel sad because of our schedule. All projects need one and it's good to try stick to it. I will repeat that I think Rainbow can be a very important part of Sugar and that we should see how integration should happen, but I'm afraid I cannot directly help you with coding, etc because as you know I'm very tied with 0.84 right now. Hope it clarifies, Tomeu On Tue, Feb 24, 2009 at 17:24, Michael Stone wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: >>[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care about > by simplifying it, by making it more generically useful, by writing some basic > .deb and .rpm packaging in order to ease testing, and by writing Sugar patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > > http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have received no > feedback more serious than a (kind) thank-you note from Walter, let alone > testing, bug reports, or patches. As you might imagine, this overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I need to do > in > the form of documenting, testing, or pushing my recent rainbows before people > will be excited about trying them out and, if that's the case, someone should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I think there's an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". > ___ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: > On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: > >> >> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > Thanks for your work! I sure hope it'll get used instead of dropped, > it's the #1 reason I looked into Sugar in the first place and the one > thing I miss most on regular "desktops" (I'm sometimes using vnc running > under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. > What exactly do I need to do to try it out within sugar-jhbuild on > Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Rainbow in jhbuild would help debugging. I don't think I am along=e in using it as a development environment. -walter On Tue, Feb 24, 2009 at 12:09 PM, Michael Stone wrote: > On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: >> On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: >> >>> >>> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html >> Thanks for your work! I sure hope it'll get used instead of dropped, >> it's the #1 reason I looked into Sugar in the first place and the one >> thing I miss most on regular "desktops" (I'm sometimes using vnc running >> under different UIDs for the same purpose). > > Sascha, > > Thanks very much for the kind reply; it's really helpful to hear that someone > thinks this work is worth pursuing. > >> What exactly do I need to do to try it out within sugar-jhbuild on >> Ubuntu intrepid (amd64)? > > Never having used sugar-jhbuild, it's hard for me to say precisely. My guess > is > that you should teach jhbuild to compile and install rainbow, then apply my > patches to sugar (rebasing if needed, since they're now two months stale): > > http://dev.laptop.org/git/users/mstone/sugar-toolkit > http://dev.laptop.org/git/users/mstone/sugar > > then see what breaks. (Which might be everything, since, as I said, rainbow > has > never been tested w/ jhbuild.) > > In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with > what you learn so that it becomes easier for others to assist. > > Michael > > P.S. - Let me know where more help is needed and I'll be happy to try to get > you unstuck. > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it - almost never happens in software development. Code is a personal expression of the programmer who wrote it. If it ever does get finished by someone else, it likely gets rewritten in the process. Best regards, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Wade Brainerd wrote: > To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because > it seemed like an interesting challenge. I'm not clear why Sugar needs more > protection from rogue activities than a normal desktop environment has from > rogue applications. > > Reinventing the desktop as a constructivist learning environment is a big > enough task for one development team / community to swallow. Reinventing > security is an altogether separate cause. They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. Users naturally want to do this. To see what happens when the operating system doesn't support it, just look at the wave upon wave of e-mail viruses that plagued Windows for so many years. Without support for safe collaborative development of this sort, Sugar has little to recommend it over XFCE and similar gtk-based iconic user interfaces. We are getting there, and with the latest improvements to view-source and Rainbow, we are beginning to have the basics in place. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Carol, you make it sound as if Rainbow was new and unknown and Michael was pushing it. That's a bit unfair. Rainbow has been shipping in the OLPC releases for quite a while, and activity authors in general do know that they simply have to respect the designated directories for saving files. For example, they do know that SUGAR_ACTIVITY_ROOT (provided by Rainbow for runtime use) is something else altogether than SUGAR_BUNDLE_PATH (set by Sugar to the installation directory). Rainbow is one of the most generally useful things brought into being by OLPC. Since Sugar activities were specifically designed to work with it, it would be a shame to not use this enhanced security framework. In particular since Sugar aims at users who need all the protection they can get. Integration with jhbuild has been problematic since the rainbow demon needs to run with super user privileges, and it would need to mess with the user management of the host machine. But it should work very well in SoaS and I for one would appreciate if it was integrated and enabled there. - Bert - On 24.02.2009, at 17:56, Carol Farlow Lerche wrote: > Michael, I think your work on Rainbow is very important, but I think > it is a bit opaque. Perhaps you could improve your documentation > and as well write a tutorial about it that would make it more > apparent how much is actually implemented and what an activity can > do with it. > > So here's an example. In the Rainbow page on w.l.o you refer to > http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD > for more information. Yet this file has several locutions of the > form "This can be implemented" and "I believe but have not > confirmed" which leave the reader unclear as to which services have > actually been implemented. Hopping over to Low-Level Activity API > the information about security doesn't correlate with the > permissions referred to in the txt file. > > Also you leave ambiguities for the reader by using the passive voice > throughout these articles. Changing from passive to active voice > answers many questions for the reader. Here is an example: > > "All writing to the file system is restricted to subdirectories of > the path given in the SUGAR_ACTIVITY_ROOT environment variable." > > Well, we know that isn't true in all cases, because activities get > installed by Sugar outside that subtree. So possibly you mean > "Rainbow prevents any activity launched by the Sugar shell from > writing to any directories except those under > SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about > reading files elsewhere in the file system? > > The scattershot documentation within several wiki pages and text > files of unknown currency is also a problem. How about a unified > document befitting such an important aspect of the Sugar architecture. > > I think demystifying Rainbow within a comprehensive document > containing a section specifically aimed at the concerns of activity > developers would go a long way toward expanding its use. > > > Carol Lerche > > > On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone > wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: > >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop > it. I have > tried to clear the way for them to use it on all the platforms they > care about > by simplifying it, by making it more generically useful, by writing > some basic > .deb and .rpm packaging in order to ease testing, and by writing > Sugar patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > >http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have > received no > feedback more serious than a (kind) thank-you note from Walter, let > alone > testing, bug reports, or patches. As you might imagine, this > overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I > need to do in > the form of documenting, testing, or pushing my recent rainbows > before people > will be excited about trying them out and, if that's the case, > someone should > tell me. Since no one has done so to date, despite repeated > overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I think > there's an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., > bringing all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > They are a single, indivisible cause, and also the entire reason for the > existence of Sugar. > > Many operating systems provide users with a set of powerful tools for > manipulating ideas and data. Sugar's purpose is to add another dimension: > to encourage users to modify and share the tools themselves. To that end, > if my friend sends me a modified copy of an activity, I must be able to > run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: >To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because >it seemed like an interesting challenge. So you've said in the past. What of it? >I'm not clear why Sugar needs more protection from rogue activities than a >normal desktop environment has from rogue applications. The justification which interests me the most goes something like: "strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster." >Reinventing the desktop as a constructivist learning environment is a big >enough task for one development team / community to swallow. Reinventing >security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. >That said, Rainbow exists, so we don't need to do anything to remove it. So >long as people step up to maintain it and help activity developers fix the >issues they run into. The issue is that rainbow "has been maintained" and its downstream users (e.g. Sugar) need to give some feedback on the intermediate results so that there will be time for its upstream author to respond to that feedback. >But Michael, what you seem to be asking for - someone to pick up your solo >project and finish it Thank you, no. I apologize if my writing contributed to this gross misunderstanding of my purpose. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:57 PM, Michael Stone wrote: > I'm not clear why Sugar needs more protection from rogue activities than a >> normal desktop environment has from rogue applications. >> > > The justification which interests me the most goes something like: "strong > protections mean that there is less risk that kids and teachers will break > things by installing software on their machines; therefore, educational > innovations will spread faster." See my comment regarding Backup, a far more useful and achievable solution to this problem. > Reinventing the desktop as a constructivist learning environment is a big >> enough task for one development team / community to swallow. Reinventing >> security is an altogether separate cause. >> > > There is no reinvention taking place here; instead, we are using both > long-standing OS features (discretionary access control; memory isolation) > and > novel OS features (network containerization, cgroup-based memory resource > limits) in new combinations as they become available. What has changed is > that > the Sugar UI and user expectations permit concentrated use of these > features. In a nutshell, all this refers to Sandboxing, which seems to be the "new hotness" in software security these days. I type this email in Google Chrome, which is a good example of that. There's nothing wrong with sandboxing or other new security techniques, I just argue that their purpose is *orthogonal* to the goals of Sugar. Apologies for incorrectly assuming that you wanted someone to finish Rainbow. As far as I know the current implementation is without major issues, if some of the more advanced features of Bitfrost are not yet implemented. Regards, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: > Bert, Are you satisfied with the number of activity developers? > Are you satisfied with the number of developers within the > deployments? Have you noticed the periodic questions on the > developer-oriented lists about Rainbow security and whether it is > causing mysterious symptoms? I'm not, and I have. I am virtually certain that Rainbow is not the major obstacle to getting more activity developers. > Asking for better documentation doesn't imply that the facility is > new. It recognizes that development has reached a local minimum in > an important component that is not well understood by many. My post > was a request to the most knowledgeable person, Michael to do the > service of taking the time to write a document that clearly lays out > > . the purpose (not in security speak but in terms of the benefits > it brings to end users), > > . the relevance of APIs versus packaging elements versus choices by > the sugar shell/infrastructure developers, > > . things that the activity developers can and can't do (given that > I, at least, hope that new developers will participate, who have > preconceptions from other environments), > > Things that are hoped for in future development (well delimited from > things that are there now.) > > Good documentation is hard, and wiki pages are only good > documentation if the wiki is maintained with great discipline (which > I fear is not the case at w.l.o). But for a subtle and complex > feature such as Rainbow, good documentation would be a motivator for > use both within and outside the sugar community. Agreed. However, what activity authors need to know about rainbow is documented, and it really is not much. For example, here http://wiki.laptop.org/go/Low-level_Activity_API#Security This is not even a full page, and if activity authors use the Python Sugar toolkit they can worry even less about this. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote: >Michael, I think your work on Rainbow is very important, but I think it is a >bit opaque. Carol, Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. >Perhaps you could improve your documentation and as well write >a tutorial about it that would make it more apparent how much is actually >implemented and what an activity can do with it. I'll see what I can cook up. >So here's an example. In the Rainbow page on w.l.o you refer to >http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more >information. Yet this file has several locutions of the form "This can be >implemented" and "I believe but have not confirmed" which leave the reader >unclear as to which services have actually been implemented. Do you have an example of documentation which you think really nailed the divide between "what is needed", "what exists", "how good is it?", and "how do I use it?" >Hopping over to Low-Level Activity API the information about security doesn't >correlate with the permissions referred to in the txt file. The purpose of the rainbow.txt document was to argue that a design /existed/ which would satisfy enough of the overall goals to be worth pursuing. The purpose of the Low-Level Activity API documentation is to explain what features of rainbow exist and can be twiddled by activities. As it happens, the main feature which exists is primitive filesystem isolation. >Also you leave ambiguities for the reader by using the passive voice >throughout these articles. Changing from passive to active voice answers >many questions for the reader. Here is an example: > >"All writing to the file system is restricted to subdirectories of the path >given in the SUGAR_ACTIVITY_ROOT environment variable." > >Well, we know that isn't true in all cases, because activities get installed >by Sugar outside that subtree. So possibly you mean "Rainbow prevents any >activity launched by the Sugar shell from writing to any directories except >those under SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about >reading files elsewhere in the file system? For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. >I think demystifying Rainbow within a comprehensive document containing a >section specifically aimed at the concerns of activity developers would go a >long way toward expanding its use. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: "How do I turn rainbow off for testing?" which, in fact, is answered in the "For Activity Developers" section. http://wiki.laptop.org/go/Rainbow#For_Activity_Developers Obviously, a couple of people also found it helpful to tweak the isolation options in detailed ways as discussed in the API docs you cited earlier. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Carol Farlow Lerche wrote: > things that the activity developers can and can't do As an aside, I yesterday uploaded a simple activity to addons.sugarlabs.org. This activity runs on os767 and soas (afaik). Your post and this discussion made me realize that I hadn't had to think about Rainbow *at all* and things Just Worked. For simple activities and/or barrier-to-entry discussions, that observation seems germane. Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
bert wrote: > On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... > > Asking for better documentation doesn't imply that the facility is > > new. It recognizes that development has reached a local minimum in > > an important component that is not well understood by many. My post > > was a request to the most knowledgeable person, Michael to do the > > service of taking the time to write a document that clearly lays out > > > > . the purpose (not in security speak but in terms of the benefits > > it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 1:30 PM, wrote: > bert wrote: > > On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: > ... > > > Asking for better documentation doesn't imply that the facility is > > > new. It recognizes that development has reached a local minimum in > > > an important component that is not well understood by many. My post > > > was a request to the most knowledgeable person, Michael to do the > > > service of taking the time to write a document that clearly lays out > > > > > > . the purpose (not in security speak but in terms of the benefits > > > it brings to end users), > > for my part, i've always felt that it's this first point of > carol's that's been missing from the docs. the functional > overview is very important: as a developer, you're asking me to > implement a bunch of new API functionality simply to make a > simple program (which may already be working well in most other unix > environments) functional. i'd like to be sold on the concept > first, before having to do a bunch of work for no (apparent) benefit > to me or my program. I'm going to bow out of this thread (back to work!) but I wanted to bring up one last point regarding Rainbow's cost to Sugar. It is my sincere hope that sometime in the future Sugar will gain the ability to seamlessly launch normal X applications alongside activities. There are a great many educational Linux applications out there that would fill in gaps in our activity lineup. I fear that Rainbow will be an obstacle to achieving this goal, as we don't have the ability to fix every application in existence to conform to our non-standard security model, and emulation hacks will never just work. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Wade Brainerd wrote:
> Backup, a far more useful and achievable
> solution to this problem.
I don't see how Rainbow, something _working_ and pretty usable on my XO right
now, is usefully compared to "backup", a solution similar in specificity to the
aphorism "be careful" and one that doesn't resemble anything working on my XO
right now. I think there are about a ton of threads about how backup might be
implemented on {,xs-}de...@l.o.
> Regards,
> -Wade
Martin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Moon-9
== .XO Bundle == http://addons.sugarlabs.org/en-US/sugar/addon/4034 http://wiki.laptop.org/images/5/51/Moon-9.xo ...or use the software update panel. == Source == http://download.sugarlabs.org/sources/honey/Moon/Moon-9.tar.bz2 == Git == http://git.sugarlabs.org/projects/moon == Features == - Code cleanup (make pylint happier) - Merged alsroot's excellent independence resolution code addition (resizes moon image to fit available display, much better for misc SoaS hardware screen resolutions) - Updated localizations (latest from Pootle, thanks all!) == Documentation == http://wiki.laptop.org/go/Moon Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Michael, 2009/2/24 Michael Stone : > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? In an ideal world, such a security system should be available to everyone, not just sugar users -- but I'm not sure which technical challenges are entailed. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] addons.sl.org sandbox
Hey all, It looks like we are having trouble with some of addons.sl.o workflow. When a developer first uploads a activity it is put in a sandbox. The instructions state that other 'logged in' users will be able to see the activity and review it. That does not currently seem to be the case:) Developers can circumvent the review process by clicking the activity name under developer tools and going to change status. >From there, you can nominate your own activity for review. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I'm happy to continue this discussion off-list if you or others feel it is inappropriate to carry it on here. However, to respond to your mail: > Thanks you for this detailed critique of my documentation efforts to date. > One > thing that I've (obviously) struggled with is understanding which audiences > require which sorts of documentation. Your continued assistance untangling > this > mess is most appreciated. > I would be happy to supply detailed editorial comments to any effort you make to provide a unified Rainbow document. ... write > a tutorial about it that would make it more apparent how much is actually > implemented and what an activity can do with it. > I'll see what I can cook up. You might consider: Specifically list aspects of program operation that are forbidden or limited in the application, by default, under the current implementation. Tell why the restriction is there, from a user-benefit perspective. If these restrictions can be overcome by configuration files or programmatic calls, list these under the restriction description. Point out explicitly where a developer would see evidence of the restriction being called into play (which log, e.g., and where is it? Do you need to turn on logging in some way to see the messages?) You might want to create a separate tutorial from the standpoint of other desktop environment developers, along the lines of "what to do to implement Rainbow in your environment." I already here voices chiming in that all anyone needs is to read the code. But could those chiming voices please recognize that there is a difference between the effort people will go to in conforming to or using a feature that they don't entirely belive in, (rather than just turning it off) compared to being provided easy access and understanding. > Do you have an example of documentation which you think really nailed the > divide between "what is needed", "what exists", "how good is it?", and "how > do > I use it?" > It is uncommon to document future features unless they are realistically expected to be implemented soon, except perhaps as an appendix of unresolved issues, or "bugs" sections as in man pages. But frequently documentation addresses features that are only present in later versions. Often this is set off by color, inline images of some kind or similar visual cues. > > As it happens, the main feature which exists is primitive filesystem > isolation. > Well, I'd stick to documenting that, and save the blue sky for an appendix. For me, these questions are largely answered by the statements, scattered > throughout the system, that rainbow operates by inventing new uids for > programs > which it is asked to isolate. However, I can certainly lay things out more > explicitly. Thank you for the reminder about active vs. passive voice. > Persons with a deep or even a moderate interest in security would understand that that was the case, but we're talking about a hoped-for community of activity developers including educators and learners that have so far proved unable to cross a rather high barrier of entry. What are the concerns of activity developers? > > To date, the only one which I have heard clearly articulated is: > > "How do I turn rainbow off for testing?" > which, in fact, is answered in the "For Activity Developers" section > In this case, perhaps we should contemplate why someone would want to turn off rainbow, rather than using information that tells them what Rainbow is preventing. Can I offer the analogy of the dreaded Windows security problems in which applications written for early versions of Windows silently broke when MS introduced new access violation error returns that the programs were unaware of? These errors could often be eliminated by end users through granting constrained privileges to various Windows resources, but instead most people just did the simple thing. They ran the application as administrator (analogous to turning Rainbow off). All the bad consequences followed. Btw I don't think it was just that developers turned off Rainbow. Users did too, because activities had been written outside the context of Rainbow, then it was turned on. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote: >Hi Michael, > >2009/2/24 Michael Stone : >> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. > >How realistic is it to make rainbow something generic that all environments >and applications could use? I consider it a realistic goal, with a few caveats. The rainbow-0.8.* redesign takes a big step in this direction by introducing an exec-wrapper interface which can be embedded in fd.o .desktop launchers, used from the CLI, and used by custom launchers like Sugar with equal ease. Privilege is acquired from a setuid helper; e.g. sudo. The design and automated tests now support limited concurrent multi-user operation, though the implementation needs a bit more work in order to operate securely in a multi-user environment. The only notable dependencies so far are on python and glibc. The caveats are: a) Usability sucks at the moment. For example, I need to implement some sort of garbage collection and some kind of "user-facing" UI, which might just be a simpler CLI wrapper. I probably also need to write a man page and to introduce more diverse error codes. b) We're going to need recent kernels for the fancier containerization stuff that I'd like to work on in the future. (Fortunately, upstream seems to be making good progress on the features I want :) c) I don't have any good idea how well or poorly the current design scales. (I think it will work fine for desktop use. I'm just not sure how far beyond that it will stretch.) More questions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] addons.sl.org sandbox
On Tue, Feb 24, 2009 at 1:53 PM, David Farning wrote: > From there, you can nominate your own activity for review. > What's the process for vetting reviewers and giving out the status? -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 20:43, Sascha Silbe wrote: > On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: > >> I'm not clear why Sugar needs more protection from rogue activities >> than a normal desktop environment has from rogue applications. > It's not that Sugar needs more protection than currently existing > desktop environments, but rather that _all_ desktop environments > need it (but currently lack it). In fact, I hope that other DEs will > start using Rainbow as well, even if just optionally. +1 Besides, if we didn't feel that children deserved better than the currently popular systems we would not have started Sugar development in the first place. Security is one aspect of this. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] future of the grab key?
since we're examining unloved features today, i have something to show and tell, too. i'd like to get input on some work i've done to get the grab key(s) on the XO working. i don't think what i've done is quite how they were originally planned to work, but maybe it's close enough. i also know erik did a bunch of work on this last fall (see extensive patches on #447), and i've never been sure why that hasn't gotten picked up, so i'd like to know more about that, too. background: i've been working on a (non-XO) project recently that led me to implement a userspace virtual keyboard. as the last step of that project, i implemented modifier-based scrolling -- i can hold a key, use the joystick (on the keyboard device in question), and instead of getting motion events, scroll-button-press events are generated and injected into the uinput device. it works very nicely. when i asked a question related to my project a few weeks ago on IRC, tomeu asked if i was thinking about the grab key. i wasn't back then, but the thought stuck with me. so: i've now implemented a fairly small daemon that sits between the XO keyboard/touchpad pair and the evdev kernel driver. it opens the keyboard and touchpad /dev/input/eventN nodes (in such a way that X will skip them when it starts), creates a third eventN node via uinput, and shuttles events in between. the only thing it does with the data is watch for the grab keys -- when it sees one, it does as described above: ensuing touchpad events are translated into a smaller number of scroll-button events, and as a result the window moves instead of the mouse pointer. but as i was finishing it up and testing it, i realized that it doesn't really do what i pictured the grab key as doing. i had pictured the grab key as causing the mouse cursor to, well, "grab" the window contents, to allow dragging it around. (just like clicking and dragging on google maps.) but what i'd done was different: when one's finger moved on the touchpad, the _scrollbars_ moved. the mouse pointer stayed stationary with respect to the window edges, and the window contents moved in the _opposite_ direction from the finger on the touchpad. since i wasn't sure what to make of this frame-of-reference reversal, i did the obvious thing: i reversed the behavior, but added a commandline option to put it back, just in case. (the original "backward" behavior still feels more correct on the joystick pointer of my original project, for instance.) since the mouse cursor remains stationary on the screen, it still doesn't feel like you're "grabbing" the contents, but it's may be more intuitive than the way it was. any thoughts on this? you can try it if you'd like: http://dev.laptop.org/git?p=users/pgf/grabkeyd it needs to be started before X, and uinput needs to be loaded. (happily, uinput is already in the XO releases.) initially the easiest way to test it is: # modprobe uinput # init 3 # ./grabkeyd -l [ check that grabkeyd is running, check /var/log/messages for failure ] # init 5 as i recall, one of the objections to erik's implementation last year was that it required the XTEST extension, which is considered a security risk. as far as i know, there's no risk to my current implementation. (other than, if it dies, you lose your mouse and keyboard. uh oh -- better run it from init. :-) because it's in a fairly critical path, grabkeyd has facility for running at an elevated scheduling priority. currently this is a SCHED_FIFO priority, which is probably safe, but perhaps overkill. it's not the default. comments solicited... paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] future of the grab key?
Paul, You are not probably not going to get much feedback from core developers on grab right now. That has nothing to do with the validity of the design or the quality of the implementation. It is entirely to do with where Sugar is in the release cycle. Testing and debugging. When the merge window opens in a few weeks you work will receive a much more through review. david On Wed, Feb 25, 2009 at 2:31 PM, wrote: > since we're examining unloved features today, i have something > to show and tell, too. > > i'd like to get input on some work i've done to get the grab > key(s) on the XO working. i don't think what i've done is quite > how they were originally planned to work, but maybe it's close > enough. i also know erik did a bunch of work on this last fall > (see extensive patches on #447), and i've never been sure why > that hasn't gotten picked up, so i'd like to know more about > that, too. > > background: i've been working on a (non-XO) project recently > that led me to implement a userspace virtual keyboard. as the last > step of that project, i implemented modifier-based scrolling -- i > can hold a key, use the joystick (on the keyboard device in > question), and instead of getting motion events, scroll-button-press > events are generated and injected into the uinput device. it > works very nicely. > > when i asked a question related to my project a few weeks ago on > IRC, tomeu asked if i was thinking about the grab key. i wasn't > back then, but the thought stuck with me. > > so: i've now implemented a fairly small daemon that sits between > the XO keyboard/touchpad pair and the evdev kernel driver. it > opens the keyboard and touchpad /dev/input/eventN nodes (in such > a way that X will skip them when it starts), creates a third > eventN node via uinput, and shuttles events in between. the only > thing it does with the data is watch for the grab keys -- when it > sees one, it does as described above: ensuing touchpad events > are translated into a smaller number of scroll-button events, and > as a result the window moves instead of the mouse pointer. > > but as i was finishing it up and testing it, i realized that it > doesn't really do what i pictured the grab key as doing. > > i had pictured the grab key as causing the mouse cursor to, well, > "grab" the window contents, to allow dragging it around. (just > like clicking and dragging on google maps.) > > but what i'd done was different: when one's finger moved on the > touchpad, the _scrollbars_ moved. the mouse pointer stayed > stationary with respect to the window edges, and the window > contents moved in the _opposite_ direction from the finger on > the touchpad. > > since i wasn't sure what to make of this frame-of-reference > reversal, i did the obvious thing: i reversed the behavior, but > added a commandline option to put it back, just in case. (the > original "backward" behavior still feels more correct on the > joystick pointer of my original project, for instance.) > > since the mouse cursor remains stationary on the screen, it still > doesn't feel like you're "grabbing" the contents, but it's may be > more intuitive than the way it was. any thoughts on this? > > you can try it if you'd like: > http://dev.laptop.org/git?p=users/pgf/grabkeyd > it needs to be started before X, and uinput needs to be loaded. > (happily, uinput is already in the XO releases.) initially the > easiest way to test it is: > # modprobe uinput > # init 3 > # ./grabkeyd -l > [ check that grabkeyd is running, check /var/log/messages > for failure ] > # init 5 > > as i recall, one of the objections to erik's implementation last > year was that it required the XTEST extension, which is considered > a security risk. as far as i know, there's no risk to my current > implementation. (other than, if it dies, you lose your mouse and > keyboard. uh oh -- better run it from init. :-) > > because it's in a fairly critical path, grabkeyd has facility for > running at an elevated scheduling priority. currently this is a > SCHED_FIFO priority, which is probably safe, but perhaps > overkill. it's not the default. > > comments solicited... > > > paul > =- > paul fox, p...@laptop.org > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] future of the grab key?
david wrote: > Paul, > > You are not probably not going to get much feedback from core > developers on grab right now. gee, way to let them all off the hook, david. :-) > > That has nothing to do with the validity of the design or the quality > of the implementation. > > It is entirely to do with where Sugar is in the release cycle. > Testing and debugging. > > When the merge window opens in a few weeks you work will receive a > much more through review. no prob. of course, i'd be really excited in a few weeks if i had no time of my own to respond to a review. ;-) paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] future of the grab key?
On Tue, Feb 24, 2009 at 3:31 PM, wrote: > since we're examining unloved features today, i have something > to show and tell, too. > > i'd like to get input on some work i've done to get the grab > key(s) on the XO working. i don't think what i've done is quite > how they were originally planned to work, but maybe it's close > enough. i also know erik did a bunch of work on this last fall > (see extensive patches on #447), and i've never been sure why > that hasn't gotten picked up, so i'd like to know more about > that, too. > > background: i've been working on a (non-XO) project recently > that led me to implement a userspace virtual keyboard. as the last > step of that project, i implemented modifier-based scrolling -- i > can hold a key, use the joystick (on the keyboard device in > question), and instead of getting motion events, scroll-button-press > events are generated and injected into the uinput device. it > works very nicely. > > when i asked a question related to my project a few weeks ago on > IRC, tomeu asked if i was thinking about the grab key. i wasn't > back then, but the thought stuck with me. > > so: i've now implemented a fairly small daemon that sits between > the XO keyboard/touchpad pair and the evdev kernel driver. it > opens the keyboard and touchpad /dev/input/eventN nodes (in such > a way that X will skip them when it starts), creates a third > eventN node via uinput, and shuttles events in between. the only > thing it does with the data is watch for the grab keys -- when it > sees one, it does as described above: ensuing touchpad events > are translated into a smaller number of scroll-button events, and > as a result the window moves instead of the mouse pointer. > > but as i was finishing it up and testing it, i realized that it > doesn't really do what i pictured the grab key as doing. > > i had pictured the grab key as causing the mouse cursor to, well, > "grab" the window contents, to allow dragging it around. (just > like clicking and dragging on google maps.) > > but what i'd done was different: when one's finger moved on the > touchpad, the _scrollbars_ moved. the mouse pointer stayed > stationary with respect to the window edges, and the window > contents moved in the _opposite_ direction from the finger on > the touchpad. > > since i wasn't sure what to make of this frame-of-reference > reversal, i did the obvious thing: i reversed the behavior, but > added a commandline option to put it back, just in case. (the > original "backward" behavior still feels more correct on the > joystick pointer of my original project, for instance.) Yes, I believe that reversing the events as you have is the correct default. > since the mouse cursor remains stationary on the screen, it still > doesn't feel like you're "grabbing" the contents, but it's may be > more intuitive than the way it was. any thoughts on this? Right. This is a subtle problem anyway, since naturally it's undesirable to require one to release the grab key, move the pointer back, press the grab key again, and repeat in order to continue scrolling. One option is to move the cursor in accordance with the finger on the touchpad, but automatically slide it back to the point of the initial grab when the finger loses contact, as though on a spring. That solution doesn't seem particularly ideal either, though. Perhaps a stationary cursor is fine, and certainly any working behavior is better than a useless button. What would be nice, though, is some feedback in the form of a cursor change. We have hand cursors (both open and closed); we also have the fleur, and double horizontal and vertical arrows. It might be quite nice to detect the axes that support scrolling (is this possible?) and change the cursor to one of these three options accordingly. - Eben > you can try it if you'd like: > http://dev.laptop.org/git?p=users/pgf/grabkeyd > it needs to be started before X, and uinput needs to be loaded. > (happily, uinput is already in the XO releases.) initially the > easiest way to test it is: > # modprobe uinput > # init 3 > # ./grabkeyd -l > [ check that grabkeyd is running, check /var/log/messages > for failure ] > # init 5 > > as i recall, one of the objections to erik's implementation last > year was that it required the XTEST extension, which is considered > a security risk. as far as i know, there's no risk to my current > implementation. (other than, if it dies, you lose your mouse and > keyboard. uh oh -- better run it from init. :-) > > because it's in a fairly critical path, grabkeyd has facility for > running at an elevated scheduling priority. currently this is a > SCHED_FIFO priority, which is probably safe, but perhaps > overkill. it's not the default. > > comments solicited... > > > paul > =- > paul fox, p...@laptop.org > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://l
Re: [Sugar-devel] future of the grab key?
eben wrote: > On Tue, Feb 24, 2009 at 3:31 PM, wrote: > > but what i'd done was different: when one's finger moved on the > > touchpad, the _scrollbars_ moved. the mouse pointer stayed > > stationary with respect to the window edges, and the window > > contents moved in the _opposite_ direction from the finger on > > the touchpad. > > > > since i wasn't sure what to make of this frame-of-reference > > reversal, i did the obvious thing: i reversed the behavior, but > > added a commandline option to put it back, just in case. (the > > original "backward" behavior still feels more correct on the > > joystick pointer of my original project, for instance.) > > Yes, I believe that reversing the events as you have is the correct default. okay -- thanks for the confirmation. > > since the mouse cursor remains stationary on the screen, it still > > doesn't feel like you're "grabbing" the contents, but it's may be > > more intuitive than the way it was. any thoughts on this? > > Right. This is a subtle problem anyway, since naturally it's > undesirable to require one to release the grab key, move the pointer > back, press the grab key again, and repeat in order to continue > scrolling. One option is to move the cursor in accordance with the > finger on the touchpad, but automatically slide it back to the point > of the initial grab when the finger loses contact, as though on a > spring. > > That solution doesn't seem particularly ideal either, though. Perhaps > a stationary cursor is fine, and certainly any working behavior is > better than a useless button. What would be nice, though, is some > feedback in the form of a cursor change. We have hand cursors (both ah, good point. currently the daemon intercepts the grab keys completely (so there's no indication to X that the cursor shape should change), but i suppose that's not necessary. if they were passed through, then the WM could surely do something clever with the cursor. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24 Feb 2009, at 17:52, Wade Brainerd wrote: > On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz > > wrote: > They are a single, indivisible cause, and also the entire reason for > the > existence of Sugar. > > Many operating systems provide users with a set of powerful tools for > manipulating ideas and data. Sugar's purpose is to add another > dimension: > to encourage users to modify and share the tools themselves. To > that end, > if my friend sends me a modified copy of an activity, I must be able > to > run it without fear of wrecking my system. > > On the contrary, learning to develop software is almost impossible > without wrecking your system once or twice. > > Backups are the correct solution to this problem, not some crazy > security system. When all you have is a hammer, everything looks > like a nail. I do very much agree about back-ups (Martin's and others school-server back-up work is in invaluable here), but the promise of Rainbow is not just about limiting the possibilities for how a system could get accidently/maliciously wrecked. For instance, how do you like the idea of 'a friend' silently harvesting all the Journal photos your kid has taken via a compromised/modified activity**? **actually Pippy and the slideshow example really creeps me out for just that reason – remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? I know Rainbow, as currently implemented, is lacking in certain areas – but Rainbow is providing something I think is valuable, that's not available elsewhere, and in a manor appropriate for the non-specialist target audience. --Gary P.S. Maybe I'm just paranoid; v.happy to be corrected. > -Wade > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest 2009-02-24
=== Sugar Digest === 1. I have spent much of the past two weeks finalizing the details of a proposal to the U.S. National Science Foundation (NSF). We are proposing to create hubs of international collaboration, leverage the diverse capabilities of partner institutions, to conduct a longitudinal study of the Sugar program on a global scale. Drafting this proposal is a first step towards to goal of rallying universities around the world to address some of the challenges I raised in a blog entry last year “A page from the Hilbert playbook”. What attracted me to this particular program, Partnerships for International Research and Education (PIRE), is that it encourages international collaboration. Sugar is global and to understand its impact, one needs to work globally. 2. I finally heard from the Free Software Foundation (FSF) that http://directory.fsf.org/project/sugar/ is listed in their directory of free software projects. I hadn't ever noticed that on their homepage they say, "Free software is the foundation of a learning society – where the tools we all use are free to share, study and modify." Is the tip of their hat to learning new? In any case, it is great to see them acknowledging the synergy between free software and learning. === Community jams, meet-ups, and meetings === 3. Mike Lee has posted some great photos from the DC Learning Club meeting, where they tried booting SoaS on a variety of netbooks (See http://www.flickr.com/photos/curiouslee/sets/72157614277170318/). === Help Wanted / Help Received === 4. It is dizzying trying to floow the pace of the activity leading up to the release of 0.84. Simon Schampijer and the release team are engaged in a testing sprint. You can join them on irc.freenode.net, #sugar. Interwoven with the testing of 0.84 is a flurry of work on Sugar on a Stick (SoaS)—indeed, much of testing is happening in that environment: Thanks to the hard work of Sebastian Dziallas and the SoaS team, Sucrose 0.83.6, the 0.84 Release Candidate 2, has find it's way into Sugar on a Stick (http://download.sugarlabs.org/soas/snapshots/1/Soas-200902231225.iso). Aleksey Lim has been chasing down bugs seemingly across every package. And Sayamindu Dasgupta and the localization team have been very patiently updating the translations. 5. Christian Marc Schmidt has been making great progress on the new static website (See http://www.christianmarcschmidt.com/projects/sugarlabs/betasite). We are still seeking more screenshots of the work of children using Sugar, i.e., "authentic" Sugar images. === Tech Talk === 6. Lionel Laské has been looking into the use of Mono as a Sugar resource, opening up to us the .NET community. Please see his post, “Mono on Sugar for dummies”, on the French .NET community site (http://www.techheadbrothers.com/Articles.aspx/developper-mono-xo). 7. S. Page, in reminding us, "Don't bet against the browser", posted a link to a Pippy-like tool for Javascript (See http://billmill.org/static/canvastutorial/). 8. Sascha Silbe "finally managed to get Linux working" on his phone, so he couldn't resist installing Sugar (See http://sascha.silbe.org/photos/dsc04708.jpg, http://sascha.silbe.org/photos/dsc04709.jpg, http://sascha.silbe.org/photos/dsc04710.jpg, and http://sascha.silbe.org/photos/dsc04711.jpg). Sascha says, "No, it isn't really usable - only 64MB of physical RAM means swapping ~30MB to SD just to start Sugar (no activities running). Sugar isn't touchscreen-"compatible" as well (there are no "plain" movements, just clicks and drags)." But it looks great. === Sugar Labs === 9. Gary Martin has generated another SOM from the past week of discussion on the IAEP mailing list (Please see http://wiki.sugarlabs.org/go/Image:2009-February-14-20-som.jpg). -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 5:24 AM, Michael Stone wrote: > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care about > by simplifying it, by making it more generically useful, by writing some basic > .deb and .rpm packaging in order to ease testing, Hi Michael, what rainbow provides is very important. The trusted-OS checks from the firmware up are important. The userland application privilege isolation is hugely important, as we are pushing for making our apps heavily network oriented, the risks of other network hosts trying to take advantage of vulnerable apps is huge. You are now talking about the implementation of rainbow that provides userland privilege isolation. One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. Maybe rainbow could insta-isolate creating selinux profiles for activities? Maybe my ignorance on matters selinux is showing? ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Martin Langhoff wrote: > Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified "secure" to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. --Ben P.S. The SELinux entry on Wikipedia contains the following gem: "Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers." signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Benjamin M. Schwartz wrote: > Martin Langhoff wrote: >> Maybe my ignorance on matters selinux is showing? ;-) > > You are not alone. Sugar/OLPC simply never had SELinux experts who > volunteered to work on Rainbow. We still don't (raise your hand if you > consider yourself proficient at writing SELinux policy!). So does anyone want to become expert at writing SELinux policy? Someone who might benefit from a Red Hat internship in Westford at the feet of the master of SELinux, Dan Walsh? http://danwalsh.livejournal.com/26904.html --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote: >You are now talking about the implementation of rainbow that provides >userland privilege isolation. For the record, "rainbow" only describes the userland privilege isolation part. The rest is just "OFW, olpcrd, olpc-update, OATS...". (If somebody knows a better way to explain this stuff, speak up!) > One thing that I wonder is whether in the push to make our OS more generic it > would make sense to push rainbow in the direction of things like smack or > selinux. I think this would have the effect of making rainbow much less generic than it currently is. On the other hand, it might still be worth doing if it made it much easier to implement important features. > Maybe rainbow could insta-isolate creating selinux profiles for activities? I've been wondering about this for some time. Basically, while my reaction when it was initially proposed it was lukewarm, for all the usual reasons [1]. Since then, I've been very gradually warming to the idea, in part as SELinux matures, in part as I get to know the technology and people [2] better, and in part as I run up against limitations of the simple Unix approach that I've taken for the last year. Therefore, while it's not how /I/ intend to proceed in the near future, I'm happy to try to work with people who feel differently. I definitely have some ideas on the subject. Michael [1]: http://lists.laptop.org/pipermail/security/2008-January/000370.html [2]: http://danwalsh.livejournal.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: >On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: >>[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > >Mikus, > >In my view, it's up to the SugarLabs folks to use Rainbow or to drop >it. I have tried to clear the way for them to use it on all the >platforms they care about by simplifying it, by making it more >generically useful, by writing some basic .deb and .rpm packaging in >order to ease testing, and by writing Sugar patches which cause Sugar >to use it. As I see it, it isn't just "up to the Sugarlabs folks" to use Rainbow. Sugarlabs care about Sugar. Sugar on any distro, and any hardware. Rainbow is tied not primarily to Sugar but to a specific distro: the OLPC fork of Fedora. Sugarlabs is loosing interest in that particular distribution, and Rainbow needs to get adopted by more distros to "survive". Sure, Sugarlabs developers also play with this Soas distro - another fork of Fedora, but a lighter one, without the hardcore developers engaged in the lower parts of the system that the OLPC fork had. Yes, I am interested in packaging Rainbow for Debian. I just haven't found time to pull it off yet. I want to finish getting Sucrose packaged first, and unfortunately am still somewhat alone in doing that. I can understand your frustration. But perhaps you need to aim differently. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmkgSUACgkQn7DbMsAkQLjSEgCgm0WmzSi0vdskJjTuf+LXE1Ud kWgAnR6cD/pqEmkyJToWq432m+SJqI0U =qGGd -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote: > Sugar/OLPC simply never had SELinux experts I'm pretty sure this is false. For instance, I know that ancient OLPC+RH kernels has SELinux enabled and I know that the SELinux folks at RH have always been excited to help me to understand their work whenever I took the time to ask them questions every few months. >It's hard to write a sandboxer like Rainbow, since it must not only appear >to work, but be verified "secure" to a high degree of confidence. That's >harder still if one is writing in a system in which one is a novice, so >the developers (principally Michael) have instead stuck to technologies >with which they are already expert. This is actually not such a big deal, in my opinion. The killer problem, as I learned from the vserver experience, is that novice activity authors /must/ be able to debug their work in any system which we might hope to ship. I don't think that I have very good ideas on how to make this part workable with technologies that are more complicated or more obscure than Unix DAC. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 12:22:13AM +0100, Jonas Smedegaard wrote: >Sugarlabs care about Sugar. Sugar on any distro, and any hardware. Yes, hence my work to write rainbow-0.8.* in a (relatively) distro-neutral fashion. >Rainbow is tied not primarily to Sugar but to a specific distro: the >OLPC fork of Fedora. This used to be true. It is substantially less true (though not completely fixed) in regard to rainbow-0.8.*. >Yes, I am interested in packaging Rainbow for Debian. I just haven't >found time to pull it off yet. I know, and I'm thankful for your offer of assistance. We'll get here soon enough; I just needed to get folks onto the same page about where things stand. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote: >remind me, Pippy's getting special case hack permission to drive a 8 line >highway through Rainbow security permissions, right? Unfortunately, no. No one has yet completed an implementation of the "gates" needed to guard access to the DS and the "glue" needed to know which DS entries to fork over to which activities. (I got partway through an implementation of the "gates", which are actually fairly simple, but didn't get to the "glue". [8.2.0 intervened.] Later, Scott approached the problem from a completely different angle, i.e. with FUSE filesystems. Hopefully, though, Tomeu's simplified data store will make further work in this area a bit simpler, if any such work occurs.) Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 25, 2009 at 12:22:13AM +0100, Jonas Smedegaard wrote: >I can understand your frustration. But perhaps you need to aim >differently. Correction: Perhaps *we* need to aim differently. It is off course not your problem - we all loose if Rainbow in reality is dropped, no matter who "did it". - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmkjAYACgkQn7DbMsAkQLhXkwCfWOXTr2nB0KoVw6SlRIVXnPa1 BZcAnAtw5KUEZNQ15VjjT7zKzh4GfL2y =QidJ -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 12:21 PM, Michael Stone wrote: > For the record, "rainbow" only describes the userland privilege isolation > part. You're right. I conflated the overarching shadow of bitfrost with rainbow. My bad. > I think this would have the effect of making rainbow much less generic than > it currently is. I'm intrigued by your comment. Do you mean "less portable", and in that case what kind of portability are you thinking of? selinux does look more generic than rainbow... And we don't have to go own the selinux path. Is smack simpler, more appropriate to our needs? As you say, selinux, smack and friends have moved forward a lot in the last 2 years. Implementation/documentation/understanding of them has matured enormously. Just having 'permissive' mode is a fantastic thing when developing sw. cheers m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Tomeu Vizoso wrote: > Michael, > > when several weeks ago you showed me in #sugar your patches to Sugar > and explained the new rainbow concept, I told you that it seemed a > good idea and that the patches looked pretty good. > > As you said Rainbow wasn't ready for 0.84, I told you that we would > talk again when work on 0.86 starts. Which it hasn't yet, afaik. > > So I don't think you should feel sad because of our schedule. All > projects need one and it's good to try stick to it. > > I will repeat that I think Rainbow can be a very important part of > Sugar and that we should see how integration should happen, but I'm > afraid I cannot directly help you with coding, etc because as you know > I'm very tied with 0.84 right now. I think, this describes quite well the current where we stand currently regarding inclusion of Rainbow. I think it is an interesting part to tackle for 0.86. This release cycle was, in terms of changing resources and environment conditions, even worse than the last one. I guess, it can always get worse ;D So there was only so much we could do - and many things that fell of the plate. Anyhow, let's try to look forward - and see what we can do for 0.86. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
