<div class="gmail_quote">On Mon, Jul 19, 2010 at 6:13 PM, <a href="mailto:pbrobinson@gmail.com">pbrobinson@gmail.com</a> <span dir="ltr"><<a href="mailto:pbrobinson@gmail.com">pbrobinson@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Mon, Jul 19, 2010 at 10:48 PM, Frederick Grose <<a href="mailto:fgrose@gmail.com">fgrose@gmail.com</a>> wrote:<br> > On Mon, Jul 19, 2010 at 5:37 PM, Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>><br> > wrote:<br> >><br> >> On Mon, Jul 19, 2010 at 1:06 PM, Frederick Grose <<a href="mailto:fgrose@gmail.com">fgrose@gmail.com</a>> wrote:<br> >> > On Mon, Jul 19, 2010 at 10:41 AM, Mel Chua <<a href="mailto:mel@melchua.com">mel@melchua.com</a>> wrote:<br> >> >><br> >> >> I'm going to have to miss today's meeting, but as an update on my task<br> >> >> from last week: <a href="http://bugs.sugarlabs.org/ticket/1798#comment:22" target="_blank">http://bugs.sugarlabs.org/ticket/1798#comment:22</a><br> >> ><br> >> ><br> >> > See this comment added<br> >> > to <a href="http://bugs.sugarlabs.org/ticket/1798#comment:23" target="_blank">http://bugs.sugarlabs.org/ticket/1798#comment:23</a> :<br> >> ><br> >> > School-based deployments may want to take advantage of the persistent<br> >> > /home/<br> >> > directory installation instead of the persistent OS overlay. The<br> >> > persistent<br> >> > home folder is not a write-once, ever-diminishing storage space.<br> >> ><br> >> > For consistency and stability reasons, the school may want to leave out<br> >> > the<br> >> > persistent OS overlay (using a temporary overlay on each boot) and just<br> >> > use<br> >> > the persistent /home/ directories to save the Learners' Journals and<br> >> > settings.<br> >> ><br> >> > If a school-wide system change were desired, the Sticks could be<br> >> > upgraded<br> >> > with a simple exchange of the /LiveOS/squashfs.img file in the base file<br> >> > system of each device or stick, perhaps, even triggered by the School<br> >> > Server.<br> >><br> >><br> >><br> >> {...}<br> >><br> >><br> >><br> >> if the size of the image changes<br> >> dramatically, are there any issues regarding how space may have been<br> >> allocated?<br> ><br> > Yes, I imagine that if all free space were allocated to the home.img file<br> > and a new, larger squashfs.img needed to fit on the disc, it would fail.<br> ><br> >><br> >> {...}<br> ><br> ><br> >><br> >> > storage space optimization is discussed on this<br> >> > page, <a href="http://wiki.sugarlabs.org/go/LiveOS_image" target="_blank">http://wiki.sugarlabs.org/go/LiveOS_image</a>.<br> ><br> > On that page, there are some reasons suggested for leaving some free space<br> > outside of the LiveOS installation.<br> <br> </div></div>We're looking to have an option added to the liveusb-creator to select<br> an option "Use entire stick for image" (or something similar) which<br> would then get rid of the sqashfs all together and install the ext3<br> partition straight to the usb stick so there's no issues with corrupt<br> overlays and other related issues as it will be a plain filesystem<br> straight onto a usb stick so there'll be no weird fu in between.<br> <br> Cheers,<br> Peter</blockquote><div><br></div><div>That is great for those with sufficient storage space. There are some compromises that suggest to me that SoaS should continue to fully support LiveOS installations even if we choose to support a non-Live installation.</div> <div><br></div><div>First is file space:</div><div><br></div><div>Using the --skipcompress option in the livecd-iso-to-disk installation script results in a pristine installation that consumed 1.49 GB on disc, and requires reformatting the USB/SD device to ext234. (I was testing on an ext2-formatted disc in VirtualBox.)</div> <div><br></div><div>With a fat32 formatted disc, the pristine image consumed 0.481 GB on disc.</div><div><br></div><div>On a 2-GB stick, 1.5 GB of space could be available for Sugar Activities or other content such as textbooks with a LiveOS installation vs 0.5 for the non-Live installation.</div> <div><br></div><div>In the future, we hope to install SoaS onto smart phones and other pocket-able devices where small images sizes will be even more important.</div><div><br></div><div>Second, related to file space, is the speed of installation, replication, and system sharing:</div> <div><br></div><div>Installation onto the fat32 disc took 2:12 minutes:seconds on VirtualBox vs. 5:06 for the ext2 disc. The smaller LiveOS image makes system installation, backups, sharing quicker.</div><div><br></div> <div> Third is reliability:</div><div><br></div><div><div>For non-specific USB/SD devices, the OLPC engineers recommend that one keep the factory formatting,</div><div>see <a href="http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device">http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device</a></div> <div><br></div><div>One may say that unexpected crashing from a overfilled persistent overlay is a reliability problem. Re-examining the failure report in <a href="http://bugs.sugarlabs.org/ticket/1798#comment:18">http://bugs.sugarlabs.org/ticket/1798#comment:18</a>, the worst failure reported suggests that in a classroom setting, the LiveOS installations worked *reliably* for several months before the overlay filled up. It seems, rather, that there was insufficient understanding of the system limitations and how to work with them. I would be upset too, if a mountain highway suddenly, and without warning, changed from 2 to 1 lane right at the hairpin turn of an outer switchback and I was in the inner lane.</div> <div><br></div><div>If one chooses to use a LiveOS persistent overlay, its consumption can be easily monitored, and a Journal backup and restore scheduled around a system refresh. It is probably even be more reliable to install without an operating system overlay, and use the volatile one created on each boot from the read-only filesystem. </div> <div><br></div><div>Fourth is versatility:</div><div><br></div><div>Not having the device's default filesystem format makes the device less versatile for other applications and systems outside of the Sugar environment. One would have a much harder time sharing files with Windows-based computers, for example.</div> </div><div><br></div><div>The greater storage capacity made available with the LiveOS, allowing one to use more of the disc free space for Activities and content, is really a versatility compromise.</div><div><br></div><div> Quicker installation and sharing and the capability to install on more devices also promotes greater adoption. That could be classified as a versatility advantage as well.</div><div><br></div><div>Easier customization of images has been developed for LiveOS installations with <a href="http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Sugar_Clone">http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Sugar_Clone</a>. This provides versatility that teachers and administrators have requested and benefits many more.</div> <div><br></div><div>Thank you for considering these ideas! --Fred</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>