[SoaS] [DP] Why current linux install systems aren't good enough for truly portable Linux installations.

[Bill Bogstad]

[I'm tagging this note as a Decision Panel message since I think it's
relevant to why I think Sugar Labs should at
a minimum do its own Linux distribution variant.  If SL is going to
promote Sugar to the masses via a live USB images
we need to be in a position to work directly on the kinds of
problems/issues that I discuss below.  I say this because I don't
think
any other Linux distribution will have the NEED to make it work for
everyone as badly as we will.  If we are willing to let the Linux
distributions decide for us in what hardware environments Sugar will
run easily/well then it is less critical.

To be fair promoting running Sugar under virtualization might be a
partial solution as well.  We would essentially push all of the
hardware compatibility issues to the  Microsoft Windows drivers that
came with the machine.

I see several downsides:

1.  Any cost arguments about not needing Windows licenses or lower
spec machines go out the window.
2. Camera  and microphone access from within virtualization products
seems to be problematic.  Any activities that
depend on this go out the window as well.
3. I'm not yet sure if there is a good way to continue to allow the
user's data let alone their activities to be stored on
removable media.]


On Tue, Sep 29, 2009 at 1:10 AM, Martin Dengler
<martin at martindengler.com> wrote:

>> >>
>> >> 1. They are designed to auto discover/configure their hardware/network
>> >> access at every boot.
>> >
>> > So is every modern major linux distro's default install.
>>
>> Sure they all try to do their best at auto discovery WHEN you install
>> them.  To a greater or lesser extent, they then hard code
>> the results of that discovery process.  A truly portable/transportable
>> (i.e. live) system can NOT ever do this.  Nor can its developers rely
>> on users doing manual configuration for the myriad corner cases.
>
> Hmm...the F12 images I'm familiar with do none of this.  The only
> "hard coding" is the installed device's UID, which is the same as
> would be for a non-removable drive.  The rpm selection isn't
> customised by hardware at install time (except manually on requst,
> again as would normally be done by a person installing things).

Sorry I'm not thinking about rpm selection.  I'm thinking about
getting the broken/inconsistent PC hardware platform to actually work.
 All the crap which still  requires people to carefully investigate PC
hardware for Linux compatibility before they buy it rather then just
walking into a store and buying which ever color 'PC' strikes their
fancy.

Even knowing the chips isn't always sufficient if the hardware vendor
has strayed too far from the reference design they got from the chip
manufacturer.  This is where manual configuration comes into play.
Kernel module options and the like.  If I'm sufficiently guru I can
track this all down and set things up for my personal computer.  I'm
not going to do this for every random machine that my library, school,
employer, relatives might own.  And I'm certainly not going to suggest
that an overworked teacher or a just learning to read eight year old
do so just so they can work on whatever computer they might have
acquired
for home use.

> Otherwise it would be really hard to create a live image using a given
> machine that was useful on different machines (which is what happens).

F12 Alpha Live won't boot on my primary test machine.  F11 did but KMS
seems to have broken my machine.  Even when I try the recommended boot
time options to turn it off, it still doesn't work.   Even if it had
worked, it would have been one of those manual corner cases that I
mentioned.   Fine for an installation that is only going to run
against a single hardware configuration.
Not so good in a portable environment.

I have a donated lapop that won't boot from a USB stick and can't use
the current Strawberry CD boot helper.  It will boot from some Linux
boot CDs just not from the Strawberrry ISO.   I'm pretty sure that
this is because  BIOS  only supports 'floppy emulation' booting and
the modern way to make a bootable Linux CD is to use isolinux with  no
emulation mode.  My reading of the syslinux/isolinux site/mailing list
is that this was (and may still be) a limitation in BIOS.  If Windows
doesn't use a feature of a standard then it probably doesn't work in
half the machines which are first shipped to that standard.  OTOH, any
machine
that supports the 'no emulation' booting probably does the full standard.

>
> The same hardware drivers are installed at install time for a "live"
> install as for a non-live, subject to the "live" image creator's whim.
> For example, check the SoaS package list at
> http://people.sugarlabs.org/~mtd - 43 xorg-x11-drv rpms for hardware

That url gives me a blank page.

> not at all related to the live installation.  Bloated, yes.  The same
> as non-"live", also yes.
>
>> Unfortunately, it seems like most of the current live systems just
>> re-run the standard auto discovery software at every boot and hope for
>> the best.
>
> No - ibid.

If I haven't responded to this in the rpm vs. hardware issues above,
let me know.

>
>> If sound doesn't work it's not that big a deal.
>
> sound autodetection is not related to removable / non-removable
> installation media.

Not directly no which is why I placed this underneath the auto
discovery section of my response for that reason.

As I see it there is a synergy going on here. Good auto
discovery/configuration of hardware allows for the possibility of
booting and running from portable media.  Better portable media
(faster/higher capacity/writable/cheaper/smaller) increases the number
of use cases where using portable media is a good fit.   In the case
of Sugar, cheap bootable USB  sticks has the potential to continue to
some extent the 1-1 model (one user per hardware device) model that
the XO-1 promoted; but at much lower direct costs  (An underlying
assumption that computers are somewhat common makes this not relevant
in the poorest parts of the world.)

>> Unaccelerated graphics is fine since I'm not really going to use
>> that environment for long.
>
> With X autodetection and all the free drivers (as above), this is not
> a difference between live and non-live images, either.

And when it fails (and I've yet to see an autodetection that doesn't
fail somewhere) we'll just have a HOWTO somewhere
to tell you what to do after you install the system in text mode to
the internal hard drive.   Not the model of use
 that I was hoping for.

>
>> >> 2. They are designed to run from what is usually thought of as
>> >> removable media (this is either a result of or the reason for #1)
>> >
>> > How so?  /etc/init.d/livesys* is all I can think of, and that's not
>> > necessary these days.
>>
>> A default Fedora install (as compared to a Live USB/CD) doesn't use
>> the same filesystems.
>
> The partition layout is specific to the installation medium (as
> always), but apart from that (which could/would be different, say,
> between a 2G USB stick and a 8 GB SD card), I don't see how that's any
> different than a 30G SSD or a 120 GB HD.

squashfs?  using dm overlays?  I suppose dm isn't a filesystem.

Bill Bogstad