[SoaS] [Sugar-devel] SOAS 2 problems

[Douglas McClendon]

On 01/29/2010 06:47 AM, Bernie Innocenti wrote:
> I'll skip over the parts that we've already discussed on #sugar.
>
>
> On Wed, 2010-01-27 at 07:30 +0100, Sebastian Dziallas wrote:
>>>    1. write normally to the filesystem (dd if=/dev/random of=foobar)
>>>    2. boom!
>>
>> Admittedly, randomly dd'ing stuff the filesystem is not the usual
>> use-case for the average Sugar user, right? As I said, others did
>> testing over the time, resulting in the assumption of the overlay being
>> the issue.
>
> Here's a usecase that triggers the corruption:
>
>     yum update
>
> If there are sufficient updates, the overlay will fill up. Another
> interesting way to trigger the corruption is waiting for the prelink
> cronjob to trigger.
>
> A possible counter-argument is that users aren't supposed to run
> updates, install new software, or alter the base system in any way.
> Well, if this were the case, why are we making the root writable in the
> first place?

Inverse strawman, nicely torn down, then posited.

The reason for writable root as opposed to readonly root is convenience. 
  There was(/is?) a fedora/redhat readonly root project for a long time, 
I forget its name.  The current method caught on, because warts and all, 
people liked the results better.  Unionfs is a similar alternatve to 
readonly root, and was also chosen enmasse by other projects.  It 
suffers from similar, but differing warts.


>
> In fact, I lied when I said that it is *impossible* to prevent the
> overlay from getting corrupted at some point. If the overlay were the
> same size or bigger than the ext3 filesystem itself (2GB), then it would
> never run out of pages.
>
> But then, why waste the extra 580MB of disk space for the squashfs
> image?

immutable installation image.

Bernie, I agree with the fundamental aspect of your argument, that a 
real install to usbstick is better than a 'live' install.  But with the 
caveat "when you have a sufficiently cheap, sufficiently large, 
sufficiently reliable/performing stick".

That caveat is become easier to get past as the months and years roll by.

In general it has been my experience that fedora/redhat devs are far too 
eager to blow off users with older hardware.  I understand it makes 
design simpler, but it is entirely at odds with a project that is aiming 
to recycle older computers in the third world.

I'd guess (I'm not speaking for anybody), that the 1G stick is still a 
target of SoaS, and will be, for at least another year or two or three. 
  Whereas fedora devs don't give a crap about that use case, any more 
than they give a crap about the usecase of my laptop without vt tech. 
(i.e. the removal of even the capability of using kqemu accelerator with 
qemu)

>
> Choosing any intermediate size for the overlay is like betting that our
> users (and their applications) will be responsible in not abusing their
> writable USB stick. Wouldn't you rather switch to a scheme that doesn't
> require warning users against such a pitfall?

Yes.  With the caveat - "when its time".  That time may be soas3, I 
personally don't care.  I don't even have kids.  But there might be a 
lot of people wanting soas on a 1G stick that would say- wait for soas4 
or 5.

Admit at least that it is a real tradeoff.


>
> Also, the squashfs compression becomes less and less attractive as we
> shave stuff from it. On IRC, we determined that documentation and
> languages are taking up *huge* amounts of space in SoaS.
>
> This might explain why the the SoaS filesystem contains a whopping 1.6GB
> of files, while F11-XO1 is just about 550MB with Gnome included!
>
> If we agree that the main purpose of SoaS is to showcase Sugar rather
> than the underlying Linux console, we may conclude that manpages and
> system documentation can be safely shaved off from the installation
> (the rpm macro is "%_installdocs 0", iirc).
>
> Since users are going to interact with activities rather than cli tools,
> we may also get rid of all the locale catalogs ("%_install_langs en" or
> something like that).
>
> This would make squashfs much less attractive, because documentation and
> locale are probably the only things that compress well.
>
>
>> [...]
>>
>> The current implementation has undeniably probably a lot more users than
>> Sugar on a Stick will ever have.
>>
>> So it might be that the current livecd-tools lacks a full-time
>> maintainer. This doesn't make all the work that happens naturally
>> upstream for testing and verifying go away, though.
>
> Upstream offers many different installation options, with different
> levels of support and testing.
>
> We picked one that seemed reasonable for our usecase, but it turned out
> that it has a number of unsolved/unsolvable issues. My point is that we
> should switch to another option *also supported by upstream*, but
> simpler and more reliable.

See points above.  Nobody is saying this is a bad idea long term, the 
question is, is that time now.  Having to deal with people like you who 
neglect that it is not a new issue, but an old one with many tradeoffs 
in the balance, is rather pointlessly time consuming.

>
>
>> So the image literally beams itself onto the USB key? That's what I call
>> a feature! Yay. :)
>>
>> What I'm saying is: You certainly don't want users to have to boot a
>> Fedora LiveCD to start a simple liveinst. But somehow your image needs
>> to get onto the USB key, if I'm not misinformed.
>
> I think we agreed that livecd-iso-to-disk is harder to use than dd, and
> requires a PC with Fedora to use.

liveusb-creator is the gui that provides the exact same functionality as 
livecd-iso-to-stick, and runs on windows as well.  Were you not aware of 
this?

>
> The Intel Moblin wrapper script which you suggested would make a better
> compromise between simplicity, safety and compatibility with other UNIX
> variants.
>
>
>> Not yet. It looks like it totally went unnoticed that we actually
>> /created/ these image files (which was by the way possible by the
>> awesome work of Martin Dengler). When being compressed with LZMA, they
>> came somewhat close to the .iso size, but took quite some time to
>> extract (on my pretty decent 3 GHz Dual Core, even).
>
> I used xz, which is pretty much the finalized standard format of lzma.
> Compression is dog slow, but decompression should be a lot faster than
> bzip2.
>
> My compressed images came out a lot smaller than the ISO: 416MB vs
> 589MB. Which, by itself, would make it the preferred distribution format
> for many users with limited bandwidth.

when lzma is used for building the livecd iso, most or all of that win 
is mute.

>
>
>> Basically, we went this way you're proposing for Blueberry already. And
>> I haven't heard back from anybody concerning the use of those files.
>> Instead, I was running around, trying to work out why it wouldn't boot
>> on my machine when the old layout would.
>
> Oh! How could this possibly happen?
>
> The build scripts might have partitioned your USB stick with the wrong
> number of heads/sectors, or failed to install the MBR...
>
> It's worth investigating, because I believe the combination of grub +
> ext3 to be actually the *most compatible* with existing BIOSes, although
> isolinux is also quite safe.
>