Re: [Sugar-devel] [Marketing] press release opportunity...
On Thu, Jul 30, 2009 at 03:23, Caroline Meekscarol...@solutiongrove.com wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: Reading things you've created on your Sugar Stick on a Windows or Mac machine. Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. The http://on-disk.com folks didn't offered their expertise on this? But anyway, we don't _need_ an expert. Rather an advanced linux user that can ask the right questions, read shell scripts, inspect a running system, etc. Already asked in the local linux user groups? Regards, Tomeu Regards, Tomeu -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
Caroline Meeks wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com mailto:g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: * Reading things you've created on your Sugar Stick on a Windows or Mac machine. * Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. I'll throw my two cents in here, too. I agree with Walter that we might need to revisit the whole concept in the long term. However, it's probably the best we can get right now. Let me put it this way: Looking at my recent composes for SoaS, those were around 390 MB. This contains the compressed squashfs image. Because of this compression, it's read-only, but it's also that small. Now in comparison, we could obviously place the whole file tree on a USB key and hack up some magic to make it boot. In fact, that's from what I see already the somehow preferred way used for the XO. But for this, we'd also need to have the file tree uncompressed (since otherwise it would be read-only again). And that could become a problem. The compression works rather well for us, so if we'd try to go this way, we'd definitely need to move the USB key size requirement up (at least 2 GB, if not even more). And then, I'm not really sure if this solves the data corruption issue (which I haven't experienced myself, so far) - because files could get destroyed if the USB key is improperly removed anyway. Caroline, maybe you could explain the way you're using to make these keys, because I've lost track about what the current way is. Regarding reading contents one created in Sugar on Windows / Mac, I think this is still quite some time away. In fact, I'm wondering whether this isn't a datastore related feature. /me thinks about this... Cheers, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
As I noted in the wiki page about this: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust 2GB Sticks are $0.60 more then 1GB sticks. If it improves reliability its definitely worth it from a sheer TCO point of view. A full install also makes it possible to browse the files from other operating systems and allows the possiblity of a VM boot helper. On Thu, Jul 30, 2009 at 9:00 AM, Sebastian Dziallas sebast...@when.comwrote: Caroline Meeks wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com mailto:g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: * Reading things you've created on your Sugar Stick on a Windows or Mac machine. * Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. I'll throw my two cents in here, too. I agree with Walter that we might need to revisit the whole concept in the long term. However, it's probably the best we can get right now. Let me put it this way: Looking at my recent composes for SoaS, those were around 390 MB. This contains the compressed squashfs image. Because of this compression, it's read-only, but it's also that small. Now in comparison, we could obviously place the whole file tree on a USB key and hack up some magic to make it boot. In fact, that's from what I see already the somehow preferred way used for the XO. But for this, we'd also need to have the file tree uncompressed (since otherwise it would be read-only again). And that could become a problem. The compression works rather well for us, so if we'd try to go this way, we'd definitely need to move the USB key size requirement up (at least 2 GB, if not even more). And then, I'm not really sure if this solves the data corruption issue (which I haven't experienced myself, so far) - because files could get destroyed if the USB key is improperly removed anyway. Caroline, maybe you could explain the way you're using to make these keys, because I've lost track about what the current way is. Regarding reading contents one created in Sugar on Windows / Mac, I think this is still quite some time away. In fact, I'm wondering whether this isn't a datastore related feature. /me thinks about this... Cheers, --Sebastian -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
On Wed, Jul 29, 2009 at 3:18 PM, Gary C Martin g...@garycmartin.com wrote: On 29 Jul 2009, at 04:10, Caroline Meeks wrote: This is a good idea! Can I also ask you and Tomeu to help me with another, complimentary approach? As I hiked up the mountain on the weekend I got a lecture from one of my friends on different file system options and journaling. He has some time to help us. Today at the Expo I went to I met someone who had one of the patents on USB sticks. She is also willing to help us. I'd like to get our problems defined, resources and documentation linked up and then put together some specific requests for help that I can put out to my linkedin, facebook, and APO networks. Can you guys help me create the wiki pages that would let people understand our problems and find what they need to learn easily for some of the specific problems we don't know how to solve. The most authoritative and frightening item I've read on this is from Mitch: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device There was a detailed discussion thread back in February at: http://lists.laptop.org/pipermail/devel/2009-February/022987.html I'm sure this is not the only culprit, but it's likely an important one. I'm no expert in the live image process but here's my current random theory for the login screen case anyway (to be proven wrong so we can move on please :-) A live image has a kind of overlay file where the actual users changes are being written, if a kid unplugs too early, or hits some other media write issue, that overlay could be corrupted. Likely loosing all user changes to the original base image (and some), the stick would still boot, but bail out when it hits the corrupt overlay. Dropping the user at a login prompt (but with nothing to login to as that part is corrupt). End of random theory. This makes sense to me and I added it to the wiki. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust You'd need to carefully analyse the broken stick images to resolve this one. Not sure of the tools you'd need. Maybe. I am currently very suspicious of our file formatting. I want to know how it works and why it was chosen. then I want to find out why Open Suse and other distributions picked their choices. I don't have any information but its feeling like we have a fine crystal file format and what we want is a file structure that wraps the files in hard plastic so they will be ok even if a few bytes are disturbed. Hopefully we'll get more info. Right now I feel like all I know is how little we know. :) Which is actually a useful piece of information. Regards, --Gary -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. -walter On Wed, Jul 29, 2009 at 7:46 PM, Caroline Meekscarol...@solutiongrove.com wrote: On Wed, Jul 29, 2009 at 3:18 PM, Gary C Martin g...@garycmartin.com wrote: On 29 Jul 2009, at 04:10, Caroline Meeks wrote: This is a good idea! Can I also ask you and Tomeu to help me with another, complimentary approach? As I hiked up the mountain on the weekend I got a lecture from one of my friends on different file system options and journaling. He has some time to help us. Today at the Expo I went to I met someone who had one of the patents on USB sticks. She is also willing to help us. I'd like to get our problems defined, resources and documentation linked up and then put together some specific requests for help that I can put out to my linkedin, facebook, and APO networks. Can you guys help me create the wiki pages that would let people understand our problems and find what they need to learn easily for some of the specific problems we don't know how to solve. The most authoritative and frightening item I've read on this is from Mitch: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device There was a detailed discussion thread back in February at: http://lists.laptop.org/pipermail/devel/2009-February/022987.html I'm sure this is not the only culprit, but it's likely an important one. I'm no expert in the live image process but here's my current random theory for the login screen case anyway (to be proven wrong so we can move on please :-) A live image has a kind of overlay file where the actual users changes are being written, if a kid unplugs too early, or hits some other media write issue, that overlay could be corrupted. Likely loosing all user changes to the original base image (and some), the stick would still boot, but bail out when it hits the corrupt overlay. Dropping the user at a login prompt (but with nothing to login to as that part is corrupt). End of random theory. This makes sense to me and I added it to the wiki. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust You'd need to carefully analyse the broken stick images to resolve this one. Not sure of the tools you'd need. Maybe. I am currently very suspicious of our file formatting. I want to know how it works and why it was chosen. then I want to find out why Open Suse and other distributions picked their choices. I don't have any information but its feeling like we have a fine crystal file format and what we want is a file structure that wraps the files in hard plastic so they will be ok even if a few bytes are disturbed. Hopefully we'll get more info. Right now I feel like all I know is how little we know. :) Which is actually a useful piece of information. Regards, --Gary -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
