[SoaS] [Sugar-devel] SOAS 2 problems

[Thomas C Gilliard]

Bernie Innocenti wrote:
> Cc'ing Warren Togami, who has been filling-in as a temporary maintainer
> for livecd-iso-to-disk. The rest of the thread, to fill him in, is here:
>
>  http://lists.sugarlabs.org/archive/soas/2010-January/thread.html#683
>
>
> On Tue, 2010-01-26 at 14:00 +0000, Peter Robinson wrote:
>
>   
>> I think your trivialising your solution way too much, and the issues
>> in general. If your proposal is so easy and so risk free don't you
>> think that most of the Live Media projects would have gone this route.
>>     
>
> Good question. My guess is that all those live distros were initially
> designed for read-only media and was incrementally evolved to work also
> with USB/SD flash drives. If you google for "live usb distro" you get
> this kind of stuff.
>
> On the other hand, most Linux distros also support traditional
> installation to hard drives which works with flash drives. These don't
> show up if you search for "live usb distro" because they don't contain
> any special-casing for USB flash drives.
>
>
>   
>>  Also who is going to do all the QA and testing on this on dozens of
>> various sticks and various other media to see what the issues are with
>> different formats, USB keys, memory cards and what ever other media or
>> formats that are used.
>>     
>
> You seem to be assuming that a standard filesystem layout with a
> standard bootloader would be less compatible with existing hardware than
> a perverse succession of filesystems nested within each other.
>
> I would rather reverse the question upon you: who will do all the QA and
> testing work to ensure that the current layout actually works?
>
> So far, nobody had even tested this russian-doll thing hard enough to
> discover a severe data loss issue which shows systematically on any
> brand and make of flash drives! There may be several other, less
> obvious, data corruption issues. For example: device mapper did not
> support I/O barriers until very recently (2.6.32? or 2.6.33?), and I
> seriously doubt that the copy-on-write snapshot can ever support the
> data ordering semantics required by ext3/ext4... especially when this
> snapshot lives on a separate file stored on top of a fat filesystem.
>
> How long has livecd-tools been around? Either we are the first users
> attempting to use the permanent storage feature for something more than
> a quick demo, or the maintainers are all dead.
>
>
>   
>> The advantages of the current way we do things are as follows:
>> - Works, tried and tested in Fedora across a lot of releases, 4
>> platforms, and 1000s of media types
>>     
>
> ...with just this one tiny unsolvable issue of becoming unmountable
> after some use :-)
>
>
>   
>> - Can be installed to a proper install as your proposing using
>> liveinst (this just needs to be documented as a procedure).
>>     
>
> This is also true of the original Live ISO image and, I suspect, of the
> direct to disk filesystem image.
>
> But I'm not proposing to stop distributing the ISO image.
>
>
>   
>> - Can be used on CDs as well if desired (your solution won't work
>> here)
>>     
>
> Right, but do we really want to push Sugar on a CD-ROM? Is this a
> use-case we even care about, given that all laser media is going extinct
> at the speed of light?
>
> But anyway, I'm not proposing to drop the ISO image, if someone likes
> it.
>
>
>   
>> - Can be easily booted on all Virtualisation solutions
>> (KVM/Zen/VMWare/Virtualbox/Fusion/Hyper-V etc) with no changes as they
>> all support booting off a CD iso image (your proposal would need the
>> VM drivers for at least storage to work properly for all of them)
>>     
>
> They also all support booting off a hard drive image, right? Which is
> what we'd do.
>
>   
>> - The QA that happens as part of all the upstream Fedora releases for
>> Live Media.
>>     
>
> ...which is rather unimpressive, given the hole we could find in 20
> minutes of normal operation.
>
>
>   
>> The disadvantages of your proposal (as I see it) are:
>> - Some one needs to do the coding to produce the images
>>     
>
> I've alread produced an image, and described how to do it. Others
> pointed out that there's already a rule in the Makefile.
>
>   
>> - No upstream QA
>> - Doesn't work in all environments that we currently support so we'd
>> need to have Yet Another Image
>> - No wide spread testing
>> - Lots of corner cases that would need to be documented or developed
>> around
>>     
>
> All the above items seem to disregard that what I've proposed is the
> most common filesystem layout used by upstream on all sort of writable
> block media.
>
> No more, no less... The very same stuff you have on your hard drive.
> Perhaps I'm not good at making this point very clear, because people
> keep asking me to do QA/testing and even write new code :-)
>
>
>   
>> I personally believe that the best way to get both capabilities would
>> be to continue to ship the Live Media as we do now and document how to
>> use liveinst to have a 'proper install' onto a USB key that is
>> bootable. This is supported upstream and is hence very well tested and
>> is known to work well.
>>     
>
> I personally think you're largely overestimating upstream's dedication
> and commitment in supporting the live USB corner case which, I'd like to
> stress one more time, currently sits unmaintained.
>
>
>   
>>  It shouldn't be too hard to even add an Activity icon or Control
>> Panel icon to start the liveinst off (does Sugar support something the
>> equivalent of a .desktop file) like Fedora puts a "Install to your
>> harddisk" icon on their Live Media desktops.
>>     
>
>   
Both already done:
*see: http://wiki.sugarlabs.org/go/Trisquel_On_A_Sugar_Toast
*also -look for activity: Trisquel-sugar/usb_creator-1.xo
> This would be indeed a great feature to have, regardless of how we solve
> the present data corruption problem.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100126/5e3e1788/attachment-0001.htm