Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
I'm sorry Martin, I thought I was answering No, there wasn't "marketing decided", it was Tomeu who thought of flavors, myself who thought of ice cream flavors (preferably fruit since "natural" wholesome sugars, a "fun treat for kids"), and sdziallas who agreed to the idea at the marketing meeting. I do clearly remember the problems we encountered due to the disconnect between the development and marketing teams - launch date was moved up, marketing had to work in panic mode; luckily only one publication noticed in the end. Since then efforts have been made by all to stay on the same page. The key takeaway is that marketing is not something that is tacked on at the end when something is ready for release, it's part of the development process. About the logo, it's the "blueberriest" one we will want, variant 4, the one we used in the marketing materials prepared for the Strawberry launch, variant 6: http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners But, again, there's no advantage to choosing the flavor/color beyond the next one. We should together pick the v3 flavor in a few months, not as a function of the 12 logos we have, but rather the catchiest and most fun one. (And we should avoid obscure insider names at all costs - that doesn't help in spreading the word.) I agree Chocolate should be on the shortlist and when the time comes, we should ask Christian for a chocolate-y logo. I like Gooseberry because it is unusual - I haven't picked one since I was a lad and a screenshot of Browse or InfoSlicer with gooseberries will be delightful. Cherry is a good candidate in a year or two (not sooner, we just did a red one). Mango is associated with orange. Raspberry could be a good purple one. Vanilla has the association "boring" or "plain"; many parlors call it "French Vanilla" or "Madagascar Vanilla" to spice it up. If we are lucky, the flavors will catch on and capture imaginations and the community (maybe even Learners!) will want to suggest future flavors :-) The surprise factor is for everyone who follows us, and particularly those who don't follow us yet: journalists, bloggers, teachers, parents. Good coverage by influential journalists and bloggers is by far the most efficient way to spread the word. Word-of-mouth is incredibly effective too, especially once journalists get ahold of it and amplify it; the best way to build word-of-mouth is to have an incredible offer... SoaS is not there yet since the classroom infrastructure (documentation, local integrators, school server, one-click install, extreme reliability, hardware compatibility list, etc.) is not ready. But that's not a problem, because we said as much in the Strawberry press release - we are building excitement while not overpromising, and steadily improving the offer. To me the best bet would be for developers who work "under the hood" to stay with the numbering system - it is precise and understandable to initiates (while being unfortunately incomprehensible to outsiders). Perhaps the best example of how this is done well is Apple - every one of their computer models has always had a specific number, but their marketing is centered on names: "MacBook", "iMac", "Mac Pro". There have been 50 million or so iPods sold, with the line renewed every six months, and each line having variants; every model has a development number, but they are all "iPods" and are only differentiated in marketing as classic, nano, shuffle, and touch. Consumers have a crystal-clear idea of what an iPod is and does. I saw on the SoaS roadmap page an entry "RH magazine story to be confirmed". Unfortunately there's no surer way to kill a news story than to talk about it months in advance. News breaks because it is unknown and of interest. When we respond to journalists with background, send visuals, discuss story angle etc. we don't talk about it on the marketing list right after, because that pulls the rug out from under the story. We wait until the story breaks (crossing our fingers for a fair and accurate report) then monitor its impact. But this is not just passive: we make news, and to make newsworthy news, we develop a campaign which also reinforces bigger ideas such as "Sugar Labs is alive & kicking & growing", "Sugar is international", "Sugar is free software developed by volunteers", "Sugar needs talented FOSS developers". Part of making news is developing relationships with good journalists, briefing them before the launch under embargo; they appreciate having a scoop and can even comment more intelligently on the story misreported by others. Of course, anyone with the time could read through all our list postings, attend all our IRC meetings, come to SugarCamps, and mail us with questions in order to be perfectly up to date about the project. But at that point, they are on the cusp of being a "contributor" ;-) Is this clear I hope? thanks Sean On Thu, Sep 10, 2009 at 12:30 AM, Martin Dengler wrote: > On Wed, Sep 09, 2009 at 11:56:25PM +0200, Sea
Re: [Sugar-devel] Project Guidelines posted
On Wed, Sep 02, 2009 at 03:51:55PM -0500, David Farning wrote: > The project guidelines are now on the wiki at > > http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines . > > Please edit as necessary. When it looks like the editing has > stopped, I ask the board the ratify the guidelines. Sorry for being late(maybe), but I have one idea in my mind - adding(as option) vote system to Project_Guidelines. The core idea is simple(but powerful) way for getting feedback and getting this feedback keep project ideas in consensus. In some cases poll could be multileveled i.e. not voting for entirely project but step by step elaboration from abstract statements to details of implementations(not unnecessary implementation, it could stop on statement level). So, idea is some kind of community driven process of project evolution. If we have agreement on more abstract level we can step dipper and can avoid situations when someone are disagree because of some points in the middle of entirely idea. Don't know how it could look in implementation details.. maybe wiki plugin, separate activity, utilizing mls and irc. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] bolzano 2009
Hi Silbe, are you planning to attend the SugarCamp in Bolzano? http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009 There's going to be a Zeitgeist meeting and will be great to discuss our journal goals with them. http://live.gnome.org/ZeitgeistHackFest2009 Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
David Farning wrote: > Thanks for joining us Douglas. > > I would like to point out that there are two separate yet interlinked > issues at hand: > 1. Easy and fast install. > 2. Running OS natively on removable solid state media. understood. > > Douglas' Liveos solved the first issue. It is very fast and easy to > install an OS to a hard drive by dd'ing the contents of the overlay to > the hard drive. To be clear, zyx-liveinstaller dds the contents of the combination of the overlay and the base. Alternately if you wanted to use the traditional anaconda-liveinst installer, that would copy just the base. (unless you tried it with a combination of the base and a shapshotted(frozen) version of the overlay. Something I told Sebastion I could try out, but am lazily biased to let zyx-liveinstaller work as long as people find it to be sufficiently qualified to the task). > I am suggesting that ease of installation to another medium is not > longer the primary usecase for SoaS. Agreed. > > The primary use case is now running Sugar and the underlying OS as > natively as possible on the removable solid state media. The primary > goals are now reliability and speed. > > The issue is not that overlays are bad/good or real file systems. The > issue is, can SoaS improve stick reliable and speed by eliminating > the overlays and writing the _contents_ of the overlay directly onto > the solid state device using a file systems which is aware of the > design characteristics of current generations of USB keys. One would certainly expect this to be the case at some point if not already, and it looks like you are deep into the task of figuring out exactly when that point is and what it looks like. > > I have been conducting some very initial tests using WAD's SD card test tools. > #1. Standard SOAS. > #2. Install the contents of the SoaS overlay to a usb key using ext2. I don't actually use LiveUSB overlays in all variation. In this case is the base(squashed ext3/4 base) also on the ext2, or is the ext2 a seperate partition for just the overlay? Not that it matters too much, but as above I just want to clarify things so I know we are on the same page. > > I am just running various methods of installing soas on USB sticks in > qemu directly from usb sticks using > > qemu -hda /dev/sd* > > My initial runs using the cheapest drives I could find at best buy > indicate that #2 has at least 10X the lifetime as #1. Again, I'm a bit confused by your wording of #2. I.e. 'the contents'. Does that mean just the small overlay, or the overlay combined with the base? Because it also factors into your 1. and 2. at the top. I.e. do you consider the result of #2 to fall into the category of 2."Running OS natively on removable solid state media."? I see (at least) 3 scenarios (and I don't follow OLPC that closely even though I own one and still intend to put it to good use ... 'one day') a) LiveOS(CD/USB/nand?) with nonpersistent ram overlay b) LiveOS with persistent overlay living on vfat with the squashed base c) LiveOS with persistent overlay living on ext alongside squashed base on vfat partition d) LiveOS with persistent overlay living on ext(2/3/4) with the squashed base e) installed (non-liveos) on ext2/3/4(/ubifs?/btrfs?) on a usb/flash/nand partition I take your 2.) to be e). Your #1 to be b) (or do you guys do d) already?). And your #2 to be either c) d) or e), i.e. not sure. I'll also reply to your other email. In any event, if distributing soas _as_ e) results in the lack of need for zyx-liveinstaller to be part of it, maybe I'll have to reprioritize the already roadmapped feature for zyx-liveinstaller to be able to run from an already installed system to fork/clone a copy of the running 'StickOS' (as opposed to LiveOS) to another diskpartition/stick. Nothing a majority of users would use, but perhaps amusing enough to justify inclusion. -dmc > > david > > > On Wed, Sep 9, 2009 at 10:27 AM, Martin Dengler > wrote: >> On Wed, Sep 09, 2009 at 06:48:53AM -0600, Douglas McClendon wrote: >>> Douglas McClendon wrote: Martin Langhoff wrote: > On Wed, Sep 9, 2009 at 4:26 AM, Douglas > McClendon wrote: >> My name is Douglas McClendon, and I created the ZyX-LiveInstaller which >> appears >> on track to becoming part of SoaS. I also can accept praise and blame >> for >> the LiveUSB persistence feature I implemented for fedora a couple years >> back, > Good to have you on board! One thing we've found is that the overlay > fs trick is neat but somewhat fragile. In brief - unclean shutdowns > and "oops, I pulled out the stick" cases very often leave the USB > stick unbootable. > > Of course, first step is fsck.vfat, but after that, we're completely > lost. Hints would be more than welcome. Ideally, something smarter can > be done during the boot itself or otherwise with a "repair" script. Unfortunate
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
David Farning wrote: > I am currently at the hypothesis stage. > > My hypothesis is that something is causing an excessive number of > reads/writes to a small portion of a USB memory stick. My first guess > is that the problem is the interaction of _cheap_ usb chips/firmware > and the filesystem overlay. Sounds extremely plausible to me. > > The test are described at http://wiki.laptop.org/go/NAND_Testing . > Each test is an instance of Sugar running off an USB stick in qemu. I skimmed and grepped for 'overlay'. Not seeing it I presume this is all installed systems, and not LiveOS+overlay. Though the proximity of this to your above hypothesis including overlays leaves me uncertain. Basically if these tests are against installed systems, I really don't have anything useful to add. But if this involves LiveOS style boot with overlay, then I still don't have much to add other than I assume/hope your tests don't trigger overlay exhaustion and confuse that with media error. -dmc > > I am not sure how accurate these test are because of qemu and system > level caching. At this point I am just running a hacked version of > the above test until the SoaS instance to fails. Standard SoaS fails > within a few hours. Installing the SoaS overlay as an ext2 filesystem > has lasted about 10X time longer before I stopped the tests. > > It is going to take me a while to understand what these tests mean (if > they mean anything) and if other qemu or system factors are screwing > up the results > > david > > On Wed, Sep 9, 2009 at 3:39 PM, Martin Dengler > wrote: >> On Wed, Sep 09, 2009 at 03:21:50PM -0500, David Farning wrote: >>> Thanks for joining us Douglas. >>> >>> I would like to point out that there are two separate yet interlinked >>> issues at hand: >>> 1. Easy and fast install. >>> 2. Running OS natively on removable solid state media. >> What do you mean by "running OS natively"? >> >>> Douglas' Liveos solved the first issue. It is very fast and easy to >>> install an OS to a hard drive by dd'ing the contents of the overlay to >>> the hard drive. >>> >>> I am suggesting that ease of installation to another medium is not >>> longer the primary usecase for SoaS. >> Caroline continues to ask for easy ways to duplicate a stick. >> >>> The primary use case is now running Sugar and the underlying OS as >>> natively as possible on the removable solid state media. The primary >>> goals are now reliability and speed. >> What does "as natively as possible" mean? >> >>> The issue is not that overlays are bad/good or real file systems. The >>> issue is, can SoaS improve stick reliable and speed by eliminating >>> the overlays and writing the _contents_ of the overlay directly onto >>> the solid state device >> Is what you're saying that it's easier to corrupt a bit on the overlay >> than it is to corrupt a bit on a non-overlay fs? >> >>> using a file systems which is aware of the design characteristics of >>> current generations of USB keys. >> Please clarify what you mean. >> >>> I have been conducting some very initial tests using WAD's SD card >>> test tools. >> Where can these be found? >> >>> #1. Standard SOAS. >>> #2. Install the contents of the SoaS overlay to a usb key using >>> # ext2. >> Meaning what exactly? >> >>> I am just running various methods of installing soas on USB sticks in >>> qemu directly from usb sticks using >>> >>> qemu -hda /dev/sd* >>> >>> My initial runs using the cheapest drives I could find at best buy >>> indicate that #2 has at least 10X the lifetime as #1. >> What are the units in which you're measuring "lifetime"? >> >>> david >> Martin >> ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Martin Dengler wrote: > On Wed, Sep 09, 2009 at 06:48:53AM -0600, Douglas McClendon wrote: >> Douglas McClendon wrote: >>> Martin Langhoff wrote: On Wed, Sep 9, 2009 at 4:26 AM, Douglas McClendon wrote: > My name is Douglas McClendon, and I created the ZyX-LiveInstaller which > appears > on track to becoming part of SoaS. I also can accept praise and blame > for > the LiveUSB persistence feature I implemented for fedora a couple years > back, Good to have you on board! One thing we've found is that the overlay fs trick is neat but somewhat fragile. In brief - unclean shutdowns and "oops, I pulled out the stick" cases very often leave the USB stick unbootable. Of course, first step is fsck.vfat, but after that, we're completely lost. Hints would be more than welcome. Ideally, something smarter can be done during the boot itself or otherwise with a "repair" script. >>> Unfortunately I don't have any easy answers. As someone who works on NDS >> Ok, more hints as various vague theories start percolating through >> my memory. > > If people care to take advantage of your expertise, I hope they can > provide the filesystems that have failed as examples. "overlay is > fragile" is about the level of FUD, AFAICS. Nothing better has been > proposed. No broken filesystems have been made available. I don't > doubt the "some sticks 'broke' when yanked out before fs's were > sync'ed" reports in and of themselves, but when this meme continues it > makes potential contributors / onlookers think there is some obvious / > neglected problem. As the implementer of the current manifestation of the LiveUSB persistence feature I'll be the first to confirm it is reasonable to consider overlay exhaustion to be a more annoying feature than it needs to be. I.e. extremely hard to detect and recover from. If someone wants to pay me a salary to improve the situation, I could, but otherwise I have more fun nds/guitar related projects to work on. And there may also be better long term ways around it than what I would do. Beyond that, I can also as mentioned confirm seeing problems with corrupted fat filesystems. Maybe all/most from NDS stuff and not LiveOS stuff. Can someone maybe tell me how I'm not understanding fsck.vfat? I get into this situation where it complains about a relatively small (3-6) set of things, and I try to submit to its requests. But its requests aren't at all as obvious as hitting 'y' to anyting fsck.ext3 asks of you. And then, when I run fsck.vfat immediately again, it asks the same questions as if it did nothing?? What am I missing? But off tangent back to what you said- unionfs is certainly an alternative to overlays, and it sounds like it may be a part of f13, or 14 or thereabouts. And unionfs as opposed to overlay for LiveOS certainly from what I know (but not from actual use/experience) does handle the overlay exhaustion scenario much more easily than the current devicemapper snapshot alternative. I of course don't like unionfs for reasons of rebootless installation preclusion... -dmc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
On Thu, Sep 10, 2009 at 12:11 PM, Douglas McClendon wrote: > Basically if these tests are against installed systems, I really don't have > anything useful to add. But if this involves LiveOS style boot with overlay, > then I still don't have much to add other than I assume/hope your tests don't > trigger overlay exhaustion and confuse that with media error. Those tests are on NAND flash, without an FTL, direct MTD and JFFS2 or UBIFS. I do have a couple of questions for you re diagnosing the issues we've seen. - During boot, how early is the overlay being mounted (initramfs?) and could something be done to fail more gracefully if the overlay is found to be corrupt? Hints to what code is controlling this would be great. - When we do have LiveUSB that refuses to boot, what fs is in the overlay? The 'livecd' tools that create the overlay just dd the file. It all seems to be internal to the Linux kernel -- if it is a FS in disguise, we could fsck it... With this kind of info, we can hopefully do more valuable testing & diagnosis... 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] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Martin Dengler wrote: >> I am suggesting that ease of installation to another medium is not >> longer the primary usecase for SoaS. > > Caroline continues to ask for easy ways to duplicate a stick. zyx-liveinstaller should be one way to duplicate sticks in the sense of going from one LiveOS to many StickOS's. liveusb-creator or livecd-iso-to-disk should be existing methods of creating duplicate LiveUSBs. > >> The primary use case is now running Sugar and the underlying OS as >> natively as possible on the removable solid state media. The primary >> goals are now reliability and speed. > > What does "as natively as possible" mean? I'm guessing it means running a ext3/4/ubi/btrfs filesystem as the rootfs on a partition of the stick, instead of the LiveUSB form of an ext4 as rootfs mounted from an image file in a squashed-fs image file, residing on a vfat or other filesystem on a partition of the stick, possibly with a readwrite devicemapper overlay which could reside on the same partition on the stick, or a different partition. -dmc > >> The issue is not that overlays are bad/good or real file systems. The >> issue is, can SoaS improve stick reliable and speed by eliminating >> the overlays and writing the _contents_ of the overlay directly onto >> the solid state device > > Is what you're saying that it's easier to corrupt a bit on the overlay > than it is to corrupt a bit on a non-overlay fs? > >> using a file systems which is aware of the design characteristics of >> current generations of USB keys. > > Please clarify what you mean. > >> I have been conducting some very initial tests using WAD's SD card >> test tools. > > Where can these be found? > >> #1. Standard SOAS. >> #2. Install the contents of the SoaS overlay to a usb key using >> # ext2. > > Meaning what exactly? > >> I am just running various methods of installing soas on USB sticks in >> qemu directly from usb sticks using >> >> qemu -hda /dev/sd* >> >> My initial runs using the cheapest drives I could find at best buy >> indicate that #2 has at least 10X the lifetime as #1. > > What are the units in which you're measuring "lifetime"? > >> david > > Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
On Thu, Sep 10, 2009 at 09:41:31AM +0200, Sean DALY wrote: > I'm sorry Martin, I thought I was answering You were but there's a lot of extra information that's sometimes hard to parse - ultimately someone needs to put an image file in a directory...so I was hoping that you would just say "yes" or "no - use [this one]" when I asked you: > > Ah - so perhaps this: > > > > http://wiki.sugarlabs.org/go/File:Logo_white_05.png > > > > ...is the logo you want, not the one I mentioned in my email: > > > > http://wiki.sugarlabs.org/go/File:Logo_white_04.png [Hoped for:] > YES - use #5 [or] > NO - use #4 But the reason I'm dragging this out even further is I got: > About the logo, it's the "blueberriest" one we will want, variant 4 Aha so it's 4...but no, wait: > the one we used in the marketing materials prepared for the Strawberry > launch, variant 6: > http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners ...so it's...6?! So do you want 4 (like you said first above) or 6 (like you said second above) or 5 (like you said earlier since you want it to be one of the ones from the beauty shot that clearly doesn't have 4 or 6)? > No, there wasn't "marketing decided", it was Tomeu who thought of > flavors, myself who thought of ice cream flavors (preferably fruit > since "natural" wholesome sugars, a "fun treat for kids"), and > sdziallas who agreed to the idea at the marketing meeting. Tomeu suggested exactly what he suggested, which was clearly NOT flavours: "Cherry-Oak" is not a flavour. You and Eben were talking about colours explicitly and nobody said _anything_ about flavours: >>> [SeanDaly] >> [Eben] > [Tomeu] >>> Nota: my idea would be for each version to change the Sugar logo >>> color too... potentially allowing troubleshooters to ask "what >>> color is the Sugar logo?" and match that to the version number. >> >> I actually think changing the colors with each release is a pretty >> awesome idea. > > So awesome that it may solve the controversial issue of naming > releases: Banana-Chocolate Sugar, Cherry-Oak Sugar, etc When I say "marketing decided ice cream", I mean: 1) marketing came up with the idea: [11:16:41] So, why not name SoaS versions as flavors, based on the boot logo color? [...] [11:18:38] caroline: I think the ice cream metaphor can really serve us 2) marketing championed it [12:30:02] sdziallas: OK for SoaS v1 with a flavor name? [...] [12:30:44] I rather like strawberry as a first one, but i don't think we have a logo that color 3) marketing called the vote: [12:34:07] Can we go with logo 06 "Strawberry" for this release? [12:34:26] we can disagree all summer over the next one (joke) [...] [12:35:54] strawberry +1 [...] [12:36:24] strawberry +1 [...] [12:36:49] strawberry +1 from me, too ;) 4) and marketing corrected me about the etymology :) It's certainly not worth the ink I've made you spill on it but it is nice to be able to say where the buck stopped with a given decision. If you don't want it pinned on you, ok :). > The key takeaway is that marketing is not something that is tacked > on at the end when something is ready for release, it's part of the > development process. Sure, that's why we're having this discussion, right? > But, again, there's no advantage to choosing the flavor/color beyond > the next one. We should together pick the v3 flavor in a few months, > not as a function of the 12 logos we have, but rather the catchiest > and most fun one. Ok, I'm convinced. > [marketing tips] > Is this clear I hope? That marketing lesson was very clear and interesting - you should teach a course! > thanks > > Sean Martin pgppfRTd3XeD9.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Thanks for taking the time to respond. I started running the tests last week to see if we could generate some data from which we could make some predictions on the reliability of various lots (model, size, firmwre) of USB memory sticks. The original idea was that name brand sticks might last longer then 'the cheapest we could find' stick I have been working with. I was thinking that different lot/filesytem combinations would gracefully degrade at consistent predictable rates. Instead, I got a rather unexpected result. Rapid failure of a lot/filesystem combination. Now I am just scrambling for an explanation. Before anyone goes out and buys a couple hundred sticks for a deployment, pilot, or pr event. With the feedback you, Tom, and Martin have provided, I'll try to refine the tests to get better data. david On Thu, Sep 10, 2009 at 5:03 AM, Douglas McClendon wrote: > David Farning wrote: >> >> Thanks for joining us Douglas. >> >> I would like to point out that there are two separate yet interlinked >> issues at hand: >> 1. Easy and fast install. >> 2. Running OS natively on removable solid state media. > > understood. > >> >> Douglas' Liveos solved the first issue. It is very fast and easy to >> install an OS to a hard drive by dd'ing the contents of the overlay to >> the hard drive. > > To be clear, zyx-liveinstaller dds the contents of the combination of the > overlay and the base. Alternately if you wanted to use the traditional > anaconda-liveinst installer, that would copy just the base. (unless you > tried it with a combination of the base and a shapshotted(frozen) version of > the overlay. Something I told Sebastion I could try out, but am lazily > biased to let zyx-liveinstaller work as long as people find it to be > sufficiently qualified to the task). > >> I am suggesting that ease of installation to another medium is not >> longer the primary usecase for SoaS. > > Agreed. > >> >> The primary use case is now running Sugar and the underlying OS as >> natively as possible on the removable solid state media. The primary >> goals are now reliability and speed. >> >> The issue is not that overlays are bad/good or real file systems. The >> issue is, can SoaS improve stick reliable and speed by eliminating >> the overlays and writing the _contents_ of the overlay directly onto >> the solid state device using a file systems which is aware of the >> design characteristics of current generations of USB keys. > > One would certainly expect this to be the case at some point if not already, > and it looks like you are deep into the task of figuring out exactly when > that point is and what it looks like. > >> >> I have been conducting some very initial tests using WAD's SD card test >> tools. >> #1. Standard SOAS. >> #2. Install the contents of the SoaS overlay to a usb key using ext2. > > I don't actually use LiveUSB overlays in all variation. In this case is the > base(squashed ext3/4 base) also on the ext2, or is the ext2 a seperate > partition for just the overlay? Not that it matters too much, but as above > I just want to clarify things so I know we are on the same page. > >> >> I am just running various methods of installing soas on USB sticks in >> qemu directly from usb sticks using >> >> qemu -hda /dev/sd* >> >> My initial runs using the cheapest drives I could find at best buy >> indicate that #2 has at least 10X the lifetime as #1. > > Again, I'm a bit confused by your wording of #2. I.e. 'the contents'. Does > that mean just the small overlay, or the overlay combined with the base? > Because it also factors into your 1. and 2. at the top. I.e. do you > consider the result of #2 to fall into the category of 2."Running OS > natively on removable solid state media."? > > I see (at least) 3 scenarios (and I don't follow OLPC that closely even > though I own one and still intend to put it to good use ... 'one day') > > a) LiveOS(CD/USB/nand?) with nonpersistent ram overlay > b) LiveOS with persistent overlay living on vfat with the squashed base > c) LiveOS with persistent overlay living on ext alongside squashed base on > vfat partition > d) LiveOS with persistent overlay living on ext(2/3/4) with the squashed > base > e) installed (non-liveos) on ext2/3/4(/ubifs?/btrfs?) on a usb/flash/nand > partition > > I take your 2.) to be e). Your #1 to be b) (or do you guys do d) already?). > And your #2 to be either c) d) or e), i.e. not sure. > > I'll also reply to your other email. > > In any event, if distributing soas _as_ e) results in the lack of need for > zyx-liveinstaller to be part of it, maybe I'll have to reprioritize the > already roadmapped feature for zyx-liveinstaller to be able to run from an > already installed system to fork/clone a copy of the running 'StickOS' (as > opposed to LiveOS) to another diskpartition/stick. Nothing a majority of > users would use, but perhaps amusing enough to justify inclusion. > > -dmc > > >> >> david >> >> >> On Wed, Sep 9, 2
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
On Thu, Sep 10, 2009 at 04:24:55AM -0600, Douglas McClendon wrote:
> And there may also be better long term ways around it than what I
> would do.
The F11-on-XO guys over at fedora-olpc-l...@redhat.com are having a
serious go at changing the partition layout for XO-1.5 deployment
images. We are creating F11/F12 filesytems/layouts for removable
(USB/SD/etc.) and fixed media (XO-1 internal NAND, XO-1.5 internal SD
card). We'd like to support copying the removeable
filesystems/layouts to a) another removable device ("cloning a
stick"); and b) another less-than-removable device (intenal NAND/SD
card, hard drive).
It'd be really great to get your expertise now to make the layout as
robust as possible, and soon when the F11-on-XO guys write up the
details of their new layout.
> -dmc
Martin
pgpMLegTtms6V.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Design] ColorButton
Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: > Hi, > > currently the ColorButton is not fully clear in it's behavior (see > http://dev.sugarlabs.org/ticket/388). Click outside the palette to close > it etc. Benjamin suggested to have an ok/cancel button to make the end > of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 > > Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click "add.."(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
On Thu, Sep 10, 2009 at 12:39 PM, David Farning wrote: > I was thinking that different lot/filesytem combinations would > gracefully degrade at consistent predictable rates. Instead, I got a > rather unexpected result. Rapid failure of a lot/filesystem > combination. Did you repartition them? Mitch Bradley explained it best: http://lists.sugarlabs.org/archive/sugar-devel/2009-April/013789.html Background reading at http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Even following his advise, journalled FSs are going to hit the device pretty hard. And if you skip journalled FSs, you're in the land of dinosaurs like ext2. life sucks, we're screwed, etc >From a distance, btrfs seems to have the nice aspects of journalled FSs without the hotspots that cut through flash devices. It may be a good candidate, coupled with following Mitch's advise. 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] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Douglas McClendon wrote: > David Farning wrote: >> >> The primary use case is now running Sugar and the underlying OS as >> natively as possible on the removable solid state media. The primary >> goals are now reliability and speed. >> >> The issue is not that overlays are bad/good or real file systems. The >> issue is, can SoaS improve stick reliable and speed by eliminating >> the overlays and writing the _contents_ of the overlay directly onto >> the solid state device using a file systems which is aware of the >> design characteristics of current generations of USB keys. > > One would certainly expect this to be the case at some point if not > already, and it looks like you are deep into the task of figuring out > exactly when that point is and what it looks like. > Yeah, this is all pretty nastily complex. I just reread the above two paragraphs, and think that in my reply I misunderstood the 2nd paragraph. But there is possible contradiction with the 1st paragraph. I now see what you are saying in the 2nd paragraph, as the overlay living in a filesystem that does wearleveling/circular-writing(ish kind of stuff). Which is different than what I previously thought you meant, i.e. having a traditional rootfs (no overlay), on a filesystem that does wearleveling/circular writing. I.e. my vague semi-osmotic understanding is that btrfs's 'copy on write' feature has something to do with more or less always writing new data in a 'circular' fashion on disk, which is a kind of wear leveling, and can possibly facilitate interesting snapshot feature stuff. I could however be way off. And I guess I can conceive of a justification for putting the just the overlay on such a filesystem. I.e. while the filesystem may not be ready for primetime as a rootfs, its ability to do the right thing(tm) vis-a-vis wearleveling on just the single readwrite overlay file, might be worth doing. -dmc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
David; It seems to me, from these discussions, that you may not be actually testing the reliability of the USB's. This is if you are testing a live fs. The unknown in the picture is the size and presence of the overlay and when it will be exhaused. This may, as Doug suggests, be what causes early "failures" in your testing of strawberry written to USB with live-usb creator or /livecd-iso-to-disk.sh / Contrast this with the latest .img files I have been constructing. These are case e) : e) installed (non-liveos) on ext2/3/4(/ubifs?/btrfs?) on a usb/flash/nand partition (I am attaching a screen shot of a type e) USB. SD12kdeSUGAR4G == I used the F12-alpha-i686-KDE-live CD to install to a 4GB SD //dev/sd(x)1 /boot ext2 200 MiB with boot flag /dev/sd(x)2/ ext4 3.5 GiB then I did the following commands in terminal: yum install @sugar-desktop yum upgrade @sugar-desktop yum upgrade metacity (want X.9) I then logged in to sugar at the KDE switcher screen entered name and color opened sugar terminal *# the following makes a Sugar only USB:* yum remove @kde-desktop yum install @sugar-desktop (to reinstall needed files) /yum install gedit (after gedit is installed:) gedit /etc/gdm/gdm.schemas * change: (to true and add sugar) --snip-- daemon/AutomaticLoginEnable b true daemon/AutomaticLogin s sugar --snip-- exit root rm -rf ~/.sugar su - pswd:xxx shutdown -h now This is quite different than a strawberry.iso installed with /livecd-iso-to-disk.sh /Which I think is case b) / NOTE ( These need a version number as the contents keep changing ie; there is a new different one for the soas-2-beta.iso) Versioning of these is ESSENTIAL as use of an old one can cause problems. ALSO: /Another completely different case to be looked at is a Sugar VMPlayer Appliance where the files are copied to a Fat16 or Fat32 formatted USB/SD. VMWorkstation files are constructed of (expandable up to 2GB slices) for Compatibility. These should behave quite differently when tested. Cordially Tom Gilliard satellit / / <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
On Thu, Sep 10, 2009 at 12:33, Martin Dengler wrote: > On Thu, Sep 10, 2009 at 09:41:31AM +0200, Sean DALY wrote: >> I'm sorry Martin, I thought I was answering > > You were but there's a lot of extra information that's sometimes hard > to parse - ultimately someone needs to put an image file in a > directory...so I was hoping that you would just say "yes" or "no - use > [this one]" when I asked you: > >> > Ah - so perhaps this: >> > >> > http://wiki.sugarlabs.org/go/File:Logo_white_05.png >> > >> > ...is the logo you want, not the one I mentioned in my email: >> > >> > http://wiki.sugarlabs.org/go/File:Logo_white_04.png > > [Hoped for:] >> YES - use #5 > [or] >> NO - use #4 > > But the reason I'm dragging this out even further is I got: > >> About the logo, it's the "blueberriest" one we will want, variant 4 > > Aha so it's 4...but no, wait: > >> the one we used in the marketing materials prepared for the Strawberry >> launch, variant 6: >> http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners > > ...so it's...6?! > > So do you want 4 (like you said first above) or 6 (like you said > second above) or 5 (like you said earlier since you want it to be one > of the ones from the beauty shot that clearly doesn't have 4 or 6)? > > >> No, there wasn't "marketing decided", it was Tomeu who thought of >> flavors, myself who thought of ice cream flavors (preferably fruit >> since "natural" wholesome sugars, a "fun treat for kids"), and >> sdziallas who agreed to the idea at the marketing meeting. > > Tomeu suggested exactly what he suggested, which was clearly NOT > flavours: "Cherry-Oak" is not a flavour. You and Eben were talking > about colours explicitly and nobody said _anything_ about flavours: I think it's most appropriate to say that this idea was developed collectively. I don't remember what I said nor why, but I think I was expressing support for someone else's earlier idea. I think most or all specific suggestions in this thread will work well and I don't think it's much worth discussing which one will be best. If someone really cares, we could define a process to decide names such as Fedora's, though I really hope we find better names than them, which I personally dislike even more than Ubuntu's. Regards, Tomeu [SeanDaly] >>> [Eben] >> [Tomeu] Nota: my idea would be for each version to change the Sugar logo color too... potentially allowing troubleshooters to ask "what color is the Sugar logo?" and match that to the version number. >>> >>> I actually think changing the colors with each release is a pretty >>> awesome idea. >> >> So awesome that it may solve the controversial issue of naming >> releases: Banana-Chocolate Sugar, Cherry-Oak Sugar, etc > > When I say "marketing decided ice cream", I mean: > > 1) marketing came up with the idea: > > [11:16:41] So, why not name SoaS versions as flavors, based > on the boot logo color? > [...] > [11:18:38] caroline: I think the ice cream metaphor can > really serve us > > 2) marketing championed it > > [12:30:02] sdziallas: OK for SoaS v1 with a flavor name? > [...] > [12:30:44] I rather like strawberry as a first one, but i > don't think we have a logo that color > > 3) marketing called the vote: > > [12:34:07] Can we go with logo 06 "Strawberry" for this > release? > [12:34:26] we can disagree all summer over the next one > (joke) > [...] > [12:35:54] strawberry +1 > [...] > [12:36:24] strawberry +1 > [...] > [12:36:49] strawberry +1 from me, too ;) > > 4) and marketing corrected me about the etymology :) > > It's certainly not worth the ink I've made you spill on it but it is > nice to be able to say where the buck stopped with a given decision. > If you don't want it pinned on you, ok :). > > >> The key takeaway is that marketing is not something that is tacked >> on at the end when something is ready for release, it's part of the >> development process. > > Sure, that's why we're having this discussion, right? > >> But, again, there's no advantage to choosing the flavor/color beyond >> the next one. We should together pick the v3 flavor in a few months, >> not as a function of the 12 logos we have, but rather the catchiest >> and most fun one. > > Ok, I'm convinced. > > >> [marketing tips] >> Is this clear I hope? > > That marketing lesson was very clear and interesting - you should > teach a course! > >> thanks >> >> Sean > > Martin > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Martin Langhoff wrote: > On Thu, Sep 10, 2009 at 12:11 PM, Douglas McClendon > wrote: >> Basically if these tests are against installed systems, I really don't have >> anything useful to add. But if this involves LiveOS style boot with overlay, >> then I still don't have much to add other than I assume/hope your tests don't >> trigger overlay exhaustion and confuse that with media error. > > Those tests are on NAND flash, without an FTL, direct MTD and JFFS2 or UBIFS. > > I do have a couple of questions for you re diagnosing the issues we've seen. > > - During boot, how early is the overlay being mounted (initramfs?) Yes. Also, there is probably room for clearer terminology. I.e. the overlay in question here is a a device (or device image on loopback accessed file), which gets combined with a base device, into a virtual device. These loops are indeed set up, and combined with devicemapper, in the initramfs at precisely the time when a normal initramfs would be mounting the real rootfs. I.e. once it is put together, it is then mounted as the real rootfs. > and could something be done to fail more gracefully if the overlay is > found to be corrupt? Hints to what code is controlling this would be > great. I think the relevent code may have somewhat recently moved from the livecd-tools package, to the mkinitramfs/dracut package. I.e. in f10 which I'm currently looking at, you want to look at /usr/libexec/mkliveinitrd in the mkinitrd package. But for f12 thats probably in dracut somewhere. In either you probably want to search for 'dmsetup' calls which create the virtual root device from the base and overlay devices(files). Yes, there may be room to detect and handle problems better there. > > - When we do have LiveUSB that refuses to boot, what fs is in the > overlay? The 'livecd' tools that create the overlay just dd the file. > It all seems to be internal to the Linux kernel -- if it is a FS in > disguise, we could fsck it... Again, it is a devicemapper snapshot device, which last I looked was rather tragically inadequately documented in the devicemapper documentation, (actually maybe that was the devicemapper mirror device I use for rebootless installation. hopefully all are better documented by now). And a normal ext4fs lives in the virtual device. I.e. the overlay is just that, an overlay, like a partially transparent tablecloth on a table. I.e. the table is really holding the food up, and the tablecloth by itself is quite useless. Yes you can fsck the resultant virtual device, though perhaps this relates to what I read in I think the most recent lwn about how raid/ssd/flash corruption, because it works in 'megablocks' can trash your fs rather much more badly than usual filesystem corruption. Also, there may be room to fsck that housing filesystem, i.e. the vfat or whatever fs is actually on the stick that contains the various components of the virtual rootfs. That gets to my other post asking about how fsck.vfat seems to be ignoring me. Finally, as you might gather from above, despite GDK's generous and amusing 'GodFather' comment, I haven't been following closely the most recent developments with livecd tools, i.e. in case maybe they've already implemented some of these things. But those places I mentioned are where you would find out. > > With this kind of info, we can hopefully do more valuable testing & > diagnosis... I hope I lessen the overall confusion/complexity rather than add to it :) -dmc > > cheers, > > > > m ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD
Martin Dengler wrote:
> On Thu, Sep 10, 2009 at 04:24:55AM -0600, Douglas McClendon wrote:
>> And there may also be better long term ways around it than what I
>> would do.
>
> The F11-on-XO guys over at fedora-olpc-l...@redhat.com are having a
> serious go at changing the partition layout for XO-1.5 deployment
> images. We are creating F11/F12 filesytems/layouts for removable
> (USB/SD/etc.) and fixed media (XO-1 internal NAND, XO-1.5 internal SD
> card). We'd like to support copying the removeable
> filesystems/layouts to a) another removable device ("cloning a
> stick"); and b) another less-than-removable device (intenal NAND/SD
> card, hard drive).
>
> It'd be really great to get your expertise now to make the layout as
> robust as possible, and soon when the F11-on-XO guys write up the
> details of their new layout.
I don't think I really have anything to add. I don't have the personal
experience running natively installed OSs on flash, either with rootfs as ext2,
ext4, or btrfs. My personal use case is being content with existing LiveUSBs,
and assuming that interesting natural progressions will happen with unionfs and
btrfs as they mature. I'm confident that whatever they have currently tested
and found best is probably better than any less informed suggestion I could
make.
-dmc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Check for binaries, not config files, when deciding if a tool is installed
Hi Michael (and others), Not sure, but it seems from src/sugar/activity/activityfactory.py (approx. line 250) of recent sugar-toolkit that rainbow is used if the path /etc/olpc-security exists on the system. If that is correct, then I recommend changing that to instead test for the existence of some binary, as the Debian packaging system (and most probably other packaging systems as well) preserve configuration files when removing a package. Only whn a package is "purged" are configuration files removed - and even then directories may be kept if it contains other files (e.g. backup files from various editors) not installed by the package. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Check for binaries, not config files, when deciding if a tool is installed
On Thu, Sep 10, 2009 at 02:41:15PM +0200, Jonas Smedegaard wrote: Not sure, but it seems from src/sugar/activity/activityfactory.py (approx. line 250) of recent sugar-toolkit that rainbow is used if the path /etc/olpc-security exists on the system. The intention is to be able to de/activate Rainbow use inside Sugar without uninstalling Rainbow. Maybe we should parse the file contents (i.e. store something in it) instead of just checking for existence. If that is correct, then I recommend changing that to instead test for the existence of some binary, as the Debian packaging system (and most probably other packaging systems as well) preserve configuration files when removing a package. An additional check for existence of the binary might be a good idea. 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] [Marketing] [IAEP] Sugar on a Stick v2 Release Naming
Great discussion. I'd love to be able to have a name for the next release because I need to talk about it a great deal these days. I say "Should we base our spin on Strawberry or the "next release"." I talk about: Should we try to combine Strawberry codebase and the new tool bar design?. Can I start calling it Blueberry? Is the new toolbar design the Blueberry style toolbar? Thanks, Caroline On Thu, Sep 10, 2009 at 7:46 AM, Tomeu Vizoso wrote: > On Thu, Sep 10, 2009 at 12:33, Martin Dengler > wrote: > > On Thu, Sep 10, 2009 at 09:41:31AM +0200, Sean DALY wrote: > >> I'm sorry Martin, I thought I was answering > > > > You were but there's a lot of extra information that's sometimes hard > > to parse - ultimately someone needs to put an image file in a > > directory...so I was hoping that you would just say "yes" or "no - use > > [this one]" when I asked you: > > > >> > Ah - so perhaps this: > >> > > >> > http://wiki.sugarlabs.org/go/File:Logo_white_05.png > >> > > >> > ...is the logo you want, not the one I mentioned in my email: > >> > > >> > http://wiki.sugarlabs.org/go/File:Logo_white_04.png > > > > [Hoped for:] > >> YES - use #5 > > [or] > >> NO - use #4 > > > > But the reason I'm dragging this out even further is I got: > > > >> About the logo, it's the "blueberriest" one we will want, variant 4 > > > > Aha so it's 4...but no, wait: > > > >> the one we used in the marketing materials prepared for the Strawberry > >> launch, variant 6: > >> http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners > > > > ...so it's...6?! > > > > So do you want 4 (like you said first above) or 6 (like you said > > second above) or 5 (like you said earlier since you want it to be one > > of the ones from the beauty shot that clearly doesn't have 4 or 6)? > > > > > >> No, there wasn't "marketing decided", it was Tomeu who thought of > >> flavors, myself who thought of ice cream flavors (preferably fruit > >> since "natural" wholesome sugars, a "fun treat for kids"), and > >> sdziallas who agreed to the idea at the marketing meeting. > > > > Tomeu suggested exactly what he suggested, which was clearly NOT > > flavours: "Cherry-Oak" is not a flavour. You and Eben were talking > > about colours explicitly and nobody said _anything_ about flavours: > > I think it's most appropriate to say that this idea was developed > collectively. I don't remember what I said nor why, but I think I was > expressing support for someone else's earlier idea. > > I think most or all specific suggestions in this thread will work well > and I don't think it's much worth discussing which one will be best. > > If someone really cares, we could define a process to decide names > such as Fedora's, though I really hope we find better names than them, > which I personally dislike even more than Ubuntu's. > > Regards, > > Tomeu > > [SeanDaly] > >>> [Eben] > >> [Tomeu] > Nota: my idea would be for each version to change the Sugar logo > color too... potentially allowing troubleshooters to ask "what > color is the Sugar logo?" and match that to the version number. > >>> > >>> I actually think changing the colors with each release is a pretty > >>> awesome idea. > >> > >> So awesome that it may solve the controversial issue of naming > >> releases: Banana-Chocolate Sugar, Cherry-Oak Sugar, etc > > > > When I say "marketing decided ice cream", I mean: > > > > 1) marketing came up with the idea: > > > > [11:16:41] So, why not name SoaS versions as flavors, based > > on the boot logo color? > > [...] > > [11:18:38] caroline: I think the ice cream metaphor can > > really serve us > > > > 2) marketing championed it > > > > [12:30:02] sdziallas: OK for SoaS v1 with a flavor name? > > [...] > > [12:30:44] I rather like strawberry as a first one, but i > > don't think we have a logo that color > > > > 3) marketing called the vote: > > > > [12:34:07] Can we go with logo 06 "Strawberry" for this > > release? > > [12:34:26] we can disagree all summer over the next one > > (joke) > > [...] > > [12:35:54] strawberry +1 > > [...] > > [12:36:24] strawberry +1 > > [...] > > [12:36:49] strawberry +1 from me, too ;) > > > > 4) and marketing corrected me about the etymology :) > > > > It's certainly not worth the ink I've made you spill on it but it is > > nice to be able to say where the buck stopped with a given decision. > > If you don't want it pinned on you, ok :). > > > > > >> The key takeaway is that marketing is not something that is tacked > >> on at the end when something is ready for release, it's part of the > >> development process. > > > > Sure, that's why we're having this discussion, right? > > > >> But, again, there's no advantage to choosing the flavor/color beyond > >> the next one. We should together pick the v3 flavor in a few months, > >> not as a function of the 12 logos we have, but rather the catchiest > >> and most fun one. > > > > Ok, I'm convinced. > > > > > >> [marketing tips] > >> Is this clear I hope? > > >
Re: [Sugar-devel] Check for binaries, not config files, when deciding if a tool is installed
On Thu, Sep 10, 2009 at 03:09:12PM +0200, Sascha Silbe wrote: On Thu, Sep 10, 2009 at 02:41:15PM +0200, Jonas Smedegaard wrote: Not sure, but it seems from src/sugar/activity/activityfactory.py (approx. line 250) of recent sugar-toolkit that rainbow is used if the path /etc/olpc-security exists on the system. The intention is to be able to de/activate Rainbow use inside Sugar without uninstalling Rainbow. Maybe we should parse the file contents (i.e. store something in it) instead of just checking for existence. I see. there is nothing technically wrong in using the existence of a file or directory as a "configuration flag". Debian does so with /etc/nologin . Just beware that if same file/folder also contains some other data, you make it awkward for users (i.e. admins) to manipulate such "flag", as simply "remove that file to disable the feature" causes potential loss of other customizations, and "rename file foo to foo.off" might cause problems as foo.off might exist already. If that is correct, then I recommend changing that to instead test for the existence of some binary, as the Debian packaging system (and most probably other packaging systems as well) preserve configuration files when removing a package. An additional check for existence of the binary might be a good idea. Indeed: If (as you write above) the intend of /etc/olpc-security check is for local admin configuration, then the code lack a check for sanity of considering rainbow at all: if rainbow is installed: if rainbow is enabled: use rainbow It seems to me that the code currently does not check if rainbow is installed, only if some rainbow config space exist - which seems wrong to me. Kin regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
thanks Martin in fact I often worry about talking too much during the marketing meetings, others not getting a word in. I'd be delighted if nonmarketing Sugar Labs team members lurked or participated, although I have clear ideas about how to work on marketing puzzles I'll never claim to have all the answers. re marketing course: in fact I have accepted Mel's invitation to do a classroom for Fedora. re logos: Strawberry=6, Blueberry=4, and 5 we'll use some other time Blueberry has been our "working" name for the next SoaS release since before the Strawberry release (we chose to have banners done in both red and blue logos so they would stay current longer) so I think we're all set with Blueberry? thanks Sean On Thu, Sep 10, 2009 at 12:33 PM, Martin Dengler wrote: > On Thu, Sep 10, 2009 at 09:41:31AM +0200, Sean DALY wrote: >> I'm sorry Martin, I thought I was answering > > You were but there's a lot of extra information that's sometimes hard > to parse - ultimately someone needs to put an image file in a > directory...so I was hoping that you would just say "yes" or "no - use > [this one]" when I asked you: > >> > Ah - so perhaps this: >> > >> > http://wiki.sugarlabs.org/go/File:Logo_white_05.png >> > >> > ...is the logo you want, not the one I mentioned in my email: >> > >> > http://wiki.sugarlabs.org/go/File:Logo_white_04.png > > [Hoped for:] >> YES - use #5 > [or] >> NO - use #4 > > But the reason I'm dragging this out even further is I got: > >> About the logo, it's the "blueberriest" one we will want, variant 4 > > Aha so it's 4...but no, wait: > >> the one we used in the marketing materials prepared for the Strawberry >> launch, variant 6: >> http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners > > ...so it's...6?! > > So do you want 4 (like you said first above) or 6 (like you said > second above) or 5 (like you said earlier since you want it to be one > of the ones from the beauty shot that clearly doesn't have 4 or 6)? > > >> No, there wasn't "marketing decided", it was Tomeu who thought of >> flavors, myself who thought of ice cream flavors (preferably fruit >> since "natural" wholesome sugars, a "fun treat for kids"), and >> sdziallas who agreed to the idea at the marketing meeting. > > Tomeu suggested exactly what he suggested, which was clearly NOT > flavours: "Cherry-Oak" is not a flavour. You and Eben were talking > about colours explicitly and nobody said _anything_ about flavours: > [SeanDaly] >>> [Eben] >> [Tomeu] Nota: my idea would be for each version to change the Sugar logo color too... potentially allowing troubleshooters to ask "what color is the Sugar logo?" and match that to the version number. >>> >>> I actually think changing the colors with each release is a pretty >>> awesome idea. >> >> So awesome that it may solve the controversial issue of naming >> releases: Banana-Chocolate Sugar, Cherry-Oak Sugar, etc > > When I say "marketing decided ice cream", I mean: > > 1) marketing came up with the idea: > > [11:16:41] So, why not name SoaS versions as flavors, based > on the boot logo color? > [...] > [11:18:38] caroline: I think the ice cream metaphor can > really serve us > > 2) marketing championed it > > [12:30:02] sdziallas: OK for SoaS v1 with a flavor name? > [...] > [12:30:44] I rather like strawberry as a first one, but i > don't think we have a logo that color > > 3) marketing called the vote: > > [12:34:07] Can we go with logo 06 "Strawberry" for this > release? > [12:34:26] we can disagree all summer over the next one > (joke) > [...] > [12:35:54] strawberry +1 > [...] > [12:36:24] strawberry +1 > [...] > [12:36:49] strawberry +1 from me, too ;) > > 4) and marketing corrected me about the etymology :) > > It's certainly not worth the ink I've made you spill on it but it is > nice to be able to say where the buck stopped with a given decision. > If you don't want it pinned on you, ok :). > > >> The key takeaway is that marketing is not something that is tacked >> on at the end when something is ready for release, it's part of the >> development process. > > Sure, that's why we're having this discussion, right? > >> But, again, there's no advantage to choosing the flavor/color beyond >> the next one. We should together pick the v3 flavor in a few months, >> not as a function of the 12 logos we have, but rather the catchiest >> and most fun one. > > Ok, I'm convinced. > > >> [marketing tips] >> Is this clear I hope? > > That marketing lesson was very clear and interesting - you should > teach a course! > >> thanks >> >> Sean > > Martin > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-base-0.85.5
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-base/sugar-base-0.85.5.tar.bz2 == News == * ObjectChooser displays USB media files, but fails to access file (datastore traceback) #1241 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.85.7
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.85.7.tar.bz2 == News == * Palette isn't being closed after activating some kinds of subwidgets #1301 * Palette will fail to open if you have just 'scrubbed' over some number of icons quickly #1312 * Secondary toolbar widget should set a minimum height #1304 * Activity entry icons in Journal should not be pre-lighting on rollover (fill/stroke colour reverses) #1313 * Hide palette group before immediate popup #1291 * Simple scheme for hidding ToolbarBox subpalettes #1300 * Stop all animators on poup/popdown invoking #1310 * Show selecting status of favorite check box in journal list view even if "start" is prelighted #1247 * Close previous palette on reseting palette property in invoker #1299 * Do not fail on immediate second palette openning for bottom icons #1292 * ObjectChooser displays USB media files, but fails to access file (datastore traceback) #1241 * Fullscreen resizing issues #1263 * Wrong calculated positions for palettes #1268 * Primary palette redraw glitch after secondary palette exposed when rolling cursor between buttons #1135 * Stop all animators while deleting palettes #1265 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.85.6
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.85.6.tar.bz2 == News == * Journal list view: jumping back to first page when popping up a palette #1235 * Do not requery if visibility wasn't changed #1250 * alt key gets stuck in favorites view #1311 * Hidden decorations of corner frame buttons #1294 * Visual artefacts on highlighted frame buttons #1285 * Journal title editing unexpected behaviour requires two clicks to edit #1283 * Details dialog blinks while requery #1271 * Process non-ds object in the right way in Journal #1262 * Show selecting status of favorite check box in journal list view even if "start" is prelighted #1247 * Journal list view: jumping back to first page when popping up a palette #1235 * Fix minor issues to cleanup sugar log #1267 * Allow sugar on non-XO hardware to register with an XS server #916 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] [IAEP] Sugar on a Stick v2 Release Naming
Hi all. I like blueberry, in spanish we can call it 'mora'. i like mora's juice ;). Rafael Ortiz On Thu, Sep 10, 2009 at 10:30 AM, Sean DALY wrote: > thanks Martin > > in fact I often worry about talking too much during the marketing > meetings, others not getting a word in. I'd be delighted if > nonmarketing Sugar Labs team members lurked or participated, although > I have clear ideas about how to work on marketing puzzles I'll never > claim to have all the answers. > > re marketing course: in fact I have accepted Mel's invitation to do a > classroom for Fedora. > > re logos: Strawberry=6, Blueberry=4, and 5 we'll use some other time > > Blueberry has been our "working" name for the next SoaS release since > before the Strawberry release (we chose to have banners done in both > red and blue logos so they would stay current longer) so I think we're > all set with Blueberry? > > thanks > > Sean > > > On Thu, Sep 10, 2009 at 12:33 PM, Martin Dengler > wrote: >> On Thu, Sep 10, 2009 at 09:41:31AM +0200, Sean DALY wrote: >>> I'm sorry Martin, I thought I was answering >> >> You were but there's a lot of extra information that's sometimes hard >> to parse - ultimately someone needs to put an image file in a >> directory...so I was hoping that you would just say "yes" or "no - use >> [this one]" when I asked you: >> >>> > Ah - so perhaps this: >>> > >>> > http://wiki.sugarlabs.org/go/File:Logo_white_05.png >>> > >>> > ...is the logo you want, not the one I mentioned in my email: >>> > >>> > http://wiki.sugarlabs.org/go/File:Logo_white_04.png >> >> [Hoped for:] >>> YES - use #5 >> [or] >>> NO - use #4 >> >> But the reason I'm dragging this out even further is I got: >> >>> About the logo, it's the "blueberriest" one we will want, variant 4 >> >> Aha so it's 4...but no, wait: >> >>> the one we used in the marketing materials prepared for the Strawberry >>> launch, variant 6: >>> http://wiki.sugarlabs.org/go/Marketing_Team/BoothBanners >> >> ...so it's...6?! >> >> So do you want 4 (like you said first above) or 6 (like you said >> second above) or 5 (like you said earlier since you want it to be one >> of the ones from the beauty shot that clearly doesn't have 4 or 6)? >> >> >>> No, there wasn't "marketing decided", it was Tomeu who thought of >>> flavors, myself who thought of ice cream flavors (preferably fruit >>> since "natural" wholesome sugars, a "fun treat for kids"), and >>> sdziallas who agreed to the idea at the marketing meeting. >> >> Tomeu suggested exactly what he suggested, which was clearly NOT >> flavours: "Cherry-Oak" is not a flavour. You and Eben were talking >> about colours explicitly and nobody said _anything_ about flavours: >> > [SeanDaly] [Eben] >>> [Tomeu] > Nota: my idea would be for each version to change the Sugar logo > color too... potentially allowing troubleshooters to ask "what > color is the Sugar logo?" and match that to the version number. I actually think changing the colors with each release is a pretty awesome idea. >>> >>> So awesome that it may solve the controversial issue of naming >>> releases: Banana-Chocolate Sugar, Cherry-Oak Sugar, etc >> >> When I say "marketing decided ice cream", I mean: >> >> 1) marketing came up with the idea: >> >> [11:16:41] So, why not name SoaS versions as flavors, based >> on the boot logo color? >> [...] >> [11:18:38] caroline: I think the ice cream metaphor can >> really serve us >> >> 2) marketing championed it >> >> [12:30:02] sdziallas: OK for SoaS v1 with a flavor name? >> [...] >> [12:30:44] I rather like strawberry as a first one, but i >> don't think we have a logo that color >> >> 3) marketing called the vote: >> >> [12:34:07] Can we go with logo 06 "Strawberry" for this >> release? >> [12:34:26] we can disagree all summer over the next one >> (joke) >> [...] >> [12:35:54] strawberry +1 >> [...] >> [12:36:24] strawberry +1 >> [...] >> [12:36:49] strawberry +1 from me, too ;) >> >> 4) and marketing corrected me about the etymology :) >> >> It's certainly not worth the ink I've made you spill on it but it is >> nice to be able to say where the buck stopped with a given decision. >> If you don't want it pinned on you, ok :). >> >> >>> The key takeaway is that marketing is not something that is tacked >>> on at the end when something is ready for release, it's part of the >>> development process. >> >> Sure, that's why we're having this discussion, right? >> >>> But, again, there's no advantage to choosing the flavor/color beyond >>> the next one. We should together pick the v3 flavor in a few months, >>> not as a function of the 12 logos we have, but rather the catchiest >>> and most fun one. >> >> Ok, I'm convinced. >> >> >>> [marketing tips] >>> Is this clear I hope? >> >> That marketing lesson was very clear and interesting - you should >> teach a course! >> >>> thanks >>> >>> Sean >> >> Martin >> >> > ___ > Marketing mailing lis
Re: [Sugar-devel] [Design] ColorButton
On 10 Sep 2009, at 12:01, Aleksey Lim wrote: On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click "add.."(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like (no other palettes use this behaviour). The click a colour to dismiss, with the addition of a 'custom colour' icon seems more natural, but looses a current nice feature where by you can pick a preset colour, see the sliders move, and then adjust them if you want to tweak. It also seems a little odd seeing both the toolbar icon and the custom icon changing colour at same time (see attachment below), though I guess in this case the toolbar icon could only change once you make a choice (and as you move a cursor around a document with colours). Anyway, all this makes me think that solving the issue by emitting colour change events early (i.e. not just when palette closes) would be a cleaner solution (more like a bug fix for a current unintended behaviour rather than redesigning an already good UI to avoid it). Regards, --Gary <> ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Pippy: "save as example" function
Hi Brian, Just wanted to ping regarding Pippy (Sucrose release cycles an all). I'd like to try and patch the UI to be resolution independent, take out some of those magic numbers ;-) apparently this is causing some issues for non XO resolution users. If I make a gitorious rep clone and fix, are you amenable (if you like the fix) to merging/releasing? Just wanted to check how tight your time availability is for this before I dive in. Regards, --Gary On 6 Sep 2009, at 18:38, Brian Jordan wrote: > Hi Gabriel, > > I like this! I will give it a test and commit it soon. Did you all > have a chance to test out the Pippy version 35 that Ben Schwartz put > together, with Groupthink-enabled collaboration? > http://activities.sugarlabs.org/en-US/sugar/addon/4041 If we can find > a good jabber server, I'd love to have a global programming session > one of these days :) > > More generally, re: pippy maintenance, I apologize for being rather > slow with testing and committing new patches and branches lately. I am > planning to devote some time to pushing this change and committing / > fixing some library and python version issues with GASP-integration in > pippy soon! > > As usual, if anyone would like to have commit access to pippy > repository mainline, let me know your gitorious username! > > http://git.sugarlabs.org/projects/pippy > > Best, > Brian > > On Sun, Sep 6, 2009 at 10:33 AM, Gabriel Eirea > wrote: >> Hi, >> >> During yesterday's ceibalJAM! a group of volunteers worked on >> improvements for Pippy. We had three main requests: >> >> 1) code comments in the examples are in English and not pootle- >> translatable >> 2) there is a need for more examples to awaken kids' curiosity >> 3) saving code in the journal is not very useful because built-in >> examples are shown in a treelist and more readily available >> >> For 3) I'm sending a patch (diff against Pippy version 34) that adds >> the "save as Pippy example" option and shows custom examples in the >> treelist. The trick is to use the $SUGAR_ACTIVITY_ROOT/data directory >> as a persistent repository for these files and show them in a >> separate >> category "My examples". This is complementary to the "save in the >> journal" functionality that can be used mainly for sharing code with >> others. >> >> For 2) we have new examples to contribute, we still need to compile >> them and translate some parts. >> >> For 1) the plan is to add localisation subdirectories in the data >> directory where built-in examples are located. If the directory >> exists, then examples are taken from there and not the english ones. >> The disadvantage is that they will still not be pootle-translatable >> so >> examples need to be sent upstream to be included in the bundle. >> >> We will welcome any thoughts. >> >> Regards, >> >> Gabriel >> >> ___ >> 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] client side windows in gtk
Hi, just a heads up that we may find some issues with newer versions of gtk. http://library.gnome.org/devel/gtk/2.17/gtk-migrating-ClientSideWindows.html Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Road to Sucrose 0.86
Hi, in today's developers meeting we made a plan on how to make Sucrose 0.86 a good and solid release. And of course we need YOU to make it a success. Here are the items with their champions and where we need help: a) Get the tarballs of the 0.85.6 release out tonight [erikos, tomeu] b) Make good release notes [erikos with community help] c) Make rpms [tomeu for Fedora, Aleksey for jhconvert, YOU for your distribution of choice] d) New Soas release [Sebastian] e) Announce widely as soon as possible [YOU can help here to announce for your distribution where the release is packaged, i.e. distribution's planets, mailing lists] f) Get the triagers ready [To be determined] We are looking for a champion of this item. Duties: Organize daily, or every second day meetings for triaging bugs with your squad. Mainly being responsive to incoming bugs. You can read more about how cool the BugSquad is at: http://wiki.sugarlabs.org/go/BugSquad page and erikos himself is happy to answer any questions to how we did rock back in the days ;p g) Testing plans [To be determined] Each feature that landed in 0.86 contains a test plan http://wiki.sugarlabs.org/go/0.86/Feature_List. Some of the tickets that got fixed do contain test cases as well. Basically we are looking for someone or a group of people that arrange those items on a wiki page so that testers can test them. h) Testing teams Once we have the packages in the distributions, we will announce it on the mailing list. You are welcome to report bugs you find into our bug tracker. Of course we would welcome any efforts to form testing teams or arrange for testing days! Best to use the mailing list to coordinate those efforts - so as many people as possible can join. i) Bug-fix team Work closely together with the triaging and testing team to get all the bugs out. You don't have to be as quick as Aleksey to contribute, just pick one of the bugs intended for 0.86 and submit the patch following the guidelines at: http://wiki.sugarlabs.org/go/Development_Team/Code_Review j) Plan the bug fix releases We will announce a plan for the time after the 0.86 release http://wiki.sugarlabs.org/go/0.86/Roadmap#Schedule We will definitely have 1 or two bug fix releases. So stay tuned. Happy bug-fixing, testing, triaging, packaging and releasing to everyone, Your release team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-presence-service 0.85.2
=Source= http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.85.2.tar.bz2 =News= Deal with unicode nick names (erikos) #889 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.85.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.85.3.tar.bz2 == News == * Wrong focus border in list view's title column #1261 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] How to make a SoaS (or liveCD) from scratch
Hi guys, basically I'm trying to do a SoaS or a live CD with the image we are using now on the XO, which has our own selection of activities and packages. The thing is that I've been looking in the Sugarlab web page unsuccessfully. Till now all I have is the .img to put in the nand in the XO, buy I'm not sure how to make a .ISO with which I can create a bootable (is that word ok?) pendrive or cd. Any guidance would be absolutely welcome. Thanks a lot for all your help -- Andres Nacelle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. Eduardo 2009/9/10 Gary C Martin : > On 10 Sep 2009, at 12:01, Aleksey Lim wrote: > >> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: >>> >>> Hi, >>> >>> currently the ColorButton is not fully clear in it's behavior (see >>> http://dev.sugarlabs.org/ticket/388). Click outside the palette to close >>> it etc. Benjamin suggested to have an ok/cancel button to make the end >>> of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 >>> >>> Do others agree? Other thoughts? >> >> Another option is that picker should contain only predefined >> colors(and maybe one custom) by default and having >> click-to-close behaviour. Then if users want to make(change) custom >> color, they click "add.."(or so) button and palette opens right panel >> and click on predefined color will just change custom color. >> >> btw having select-to-close behavior(at least by default) we will keep >> things consistent, e.g. to select suboptions from palette menus, user >> needs only one click. > > Is it possible to emit the colour change event as soon as a colour is > clicked? Or, perhaps emit as soon as the mouse leaves the palette area? > > I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like > (no other palettes use this behaviour). The click a colour to dismiss, with > the addition of a 'custom colour' icon seems more natural, but looses a > current nice feature where by you can pick a preset colour, see the sliders > move, and then adjust them if you want to tweak. It also seems a little odd > seeing both the toolbar icon and the custom icon changing colour at same > time (see attachment below), though I guess in this case the toolbar icon > could only change once you make a choice (and as you move a cursor around a > document with colours). > > Anyway, all this makes me think that solving the issue by emitting colour > change events early (i.e. not just when palette closes) would be a cleaner > solution (more like a bug fix for a current unintended behaviour rather than > redesigning an already good UI to avoid it). > > Regards, > --Gary > > > > > > ___ > 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] [Design] ColorButton
On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: > Should the toolbar icon for the colors palette have a down arrow like > with the other toolbar button icons? After all, it doesn't execute a > primary action of its pallete when clicking, instead it reveals its > palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. Regards, --Gary > Eduardo > > 2009/9/10 Gary C Martin : >> On 10 Sep 2009, at 12:01, Aleksey Lim wrote: >> >>> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/ 388#comment:7 Do others agree? Other thoughts? >>> >>> Another option is that picker should contain only predefined >>> colors(and maybe one custom) by default and having >>> click-to-close behaviour. Then if users want to make(change) custom >>> color, they click "add.."(or so) button and palette opens right >>> panel >>> and click on predefined color will just change custom color. >>> >>> btw having select-to-close behavior(at least by default) we will >>> keep >>> things consistent, e.g. to select suboptions from palette menus, >>> user >>> needs only one click. >> >> Is it possible to emit the colour change event as soon as a colour is >> clicked? Or, perhaps emit as soon as the mouse leaves the palette >> area? >> >> I tried some quick mockups, the OK/Cancel doesn't feel very Sugar >> UI like >> (no other palettes use this behaviour). The click a colour to >> dismiss, with >> the addition of a 'custom colour' icon seems more natural, but >> looses a >> current nice feature where by you can pick a preset colour, see the >> sliders >> move, and then adjust them if you want to tweak. It also seems a >> little odd >> seeing both the toolbar icon and the custom icon changing colour at >> same >> time (see attachment below), though I guess in this case the >> toolbar icon >> could only change once you make a choice (and as you move a cursor >> around a >> document with colours). >> >> Anyway, all this makes me think that solving the issue by emitting >> colour >> change events early (i.e. not just when palette closes) would be a >> cleaner >> solution (more like a bug fix for a current unintended behaviour >> rather than >> redesigning an already good UI to avoid it). >> >> Regards, >> --Gary >> >> >> >> >> >> ___ >> 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] [support-gang] Answering teacher and other users questions on Launchpad
Caroline Meeks writes: > If you'd like to answer user questions please > consider subscribing here. > > https://answers.launchpad.net/soas/+answer-contact Done. I also added "french" as my favorite language for questions, I will redirect french people with questions to launchpad. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to make a SoaS (or liveCD) from scratch
On Thu, Sep 10, 2009 at 06:43:31PM -0300, Andrés Nacelle wrote: > Hi guys, basically I'm trying to do a SoaS or a live CD with the image we > are using now on the XO, which has our own selection of activities and > packages. You want to take an XO-1's filesystem from its NAND and make it bootable on another machine via a USB key? It might be easier (but it's by no means quick, and probably not easy either) to re-create the SoaS .ISO. Based on the information at the top of: http://cgit.sugarlabs.org/soas/mainline/tree/BUILDING ...you could: git clone git://git.sugarlabs.org/soas/devxo.git xo-soas cd xo-soas mkdir images cache echo "soas00" > images/lastbuild sudo ./build ...to check that you can build everything. If it works you should end up with about 10 gigs less of disk space and a lot of files in images/, one of which will be soas01xo.img. You will then have images/soas01xo.tree/, which contains the files that went into that .img. You can modify the images/soas01xo.tree/ files and then cd images touch soas01xo.tree sudo make -f ../Makefile soas01xo.img ...to re-create the .img file. Martin pgpoD2tiE7g76.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to make a SoaS (or liveCD) from scratch
On Fri, Sep 11, 2009 at 03:01:47AM +0100, Martin Dengler wrote: > On Thu, Sep 10, 2009 at 06:43:31PM -0300, Andrés Nacelle wrote: > > Hi guys, basically I'm trying to do a SoaS or a live CD with the image we > > are using now on the XO, which has our own selection of activities and > > packages. > > You want to take an XO-1's filesystem from its NAND and make it > bootable on another machine via a USB key? > > It might be easier (but it's by no means quick, and probably not easy > either) to re-create the SoaS .ISO. > > Based on the information at the top of: > > http://cgit.sugarlabs.org/soas/mainline/tree/BUILDING > > ...you could: > > git clone git://git.sugarlabs.org/soas/devxo.git xo-soas That should be: git clone git://git.sugarlabs.org/soas/mainline.git xo-soas > Martin pgpvRHbrysYPW.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [GPA] communications and tomorrow
On Thu, Sep 10, 2009 at 9:09 PM, Caroline Meeks wrote: > > For the teachers, I am trying out Launchpad as our place to communicate > between teachers and community. I don't want to over load them with either > all of our discusisons, IAEP or Sugar Devel. Its my theory that they do not > have time for tons of email and don't have the well practice email coping > skills you and I have. > But all theories. Open for discussion. I agree with not overloading the teachers. Unfiltered sugar-devel is not something for which most (any?) teachers are likely to have the time let alone the interest. On the other hand, letting them know what is going on about things directly related to their school would keep them in the loop.. I have a bias against something like Launchpad for keeping people generally informed of the 'state of the environment'. It's great for tracking things, but it's a pull rather then push tool. You have to more or less go there to find things out about what is going on. Email just flows by and you can learn about what is going on when you have the time and ignore/delete it when you don't. Obviously if traffic is too high people will just tune out entirely. 'Too high' is different for everyone, but is going to be higher the more connected the traffic is to something you are already actively involved in. Discussing how to fix problems at GPA is going to be much more interesting (if not completely understood) then random email. I would hope this would keep them more engaged. BTW, I haven't used it myself; but I've heard good things about RT (Request Tracker) software. http://bestpractical.com/rt/. It structures email so that you have the tracking ability of something like Launchpad, but the informality of email. Or at least that's my impression from hearing about it from various people. Unfortunately, I don't know of any free hosting for RT. > See you tomorrow? I don't recall knowing anything about what's going on tomorrow. In any case, I'm not in the position to be anywhere anyway. Bill ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] installing Surf on 0.82?
I am trying to install Surf on 0.82 http://dev.laptop.org/~bobbyp/surf/ I have to tried to install the dependencies as written in the notes: sudo yum install pywebkitgtk WebKit-gtk gnome-python2-gconf i have enabled the repos for: fedora-updates-newkey.repo fedora-updates.repo fedora.repo fedora-updates-testing-newkey.repo fedora-updates-testing.repo and disabled olpc-development.repo I am able to install all the dependencies except gnome-python2-gconf i get the error missing dependency: gnome-python2 but when i try to update gnome-python2 yum tells me that it is already installed, w/ the same version number that yum asked for earlier. would appreciate any advice -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
