On Tue, Jan 26, 2010 at 1:15 PM, Bernie Innocenti <<a href="mailto:bernie@codewiz.org">bernie@codewiz.org</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Mon, 2010-01-25 at 11:09 -0700, Douglas McClendon wrote: > I don't think you understand the infrastructure yet. The USB stick > being full isn't an issue, because the new overlay is in RAM only. The > only way the user would fill up the second in RAM one, is the same way > they would fill it up while using a nonpersistent liveusb or livecd. > I.e. using it to the point that the ram available for it (by default > half the ram available) fills up. Clearly you didn't read what I said > enough to understand the whole warning to the user about how this was a > rescue mode to recover their data and reset the overlay. Nothing more, > nothing less. </div>I've read and understood everything the first time, but thanks for the clarification. Still, it looks very complicated and kludgy compared to the clean solution of not doing anything at all: no squashfs, no loopback mounts, no dm-snap, no warning messages, no recovery modes... No bugs at all. Do you see a reason why a simple filesystem layout would be undesiderable on today's 4GB flash drives? <div class="im"> > Either file a bug (and cc me) if you want it fixed, or not if you don't. </div>I'd like it fixed by skipping livecd-tools altogether. <div class="im"> > Please, stop criticizing, and start coding. If you provide a better > implementation, the world will thank you. If all you can do is > criticize without improving the code, to the point of alienating > developers who can fix the legitimate problems you mention, then please > shut up. </div>You see, there's nothing to code in my proposal. Only code to remove, once we've agreed that this is the solution we should adopt. </blockquote><div> 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. 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. 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 - Can be installed to a proper install as your proposing using liveinst (this just needs to be documented as a procedure). - Can be used on CDs as well if desired (your solution won't work here) - 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) - The QA that happens as part of all the upstream Fedora releases for Live Media. The disadvantages of your proposal (as I see it) are: - Some one needs to do the coding to produce the images - 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 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. 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. Regards, Peter </div></div>