[SoaS] [Marketing] Generating a list of SoaS spins

[Martin Dengler]

On Tue, Sep 29, 2009 at 12:51:58AM -0400, Bill Bogstad wrote:
> On Mon, Sep 28, 2009 at 9:08 PM, Martin Dengler
> <martin at martindengler.com> wrote:
> > On Mon, Sep 28, 2009 at 08:22:34PM -0400, Bill Bogstad wrote:
> >> On Mon, Sep 28, 2009 at 4:50 PM, Martin Dengler
> >> <martin at martindengler.com> wrote:
> >> > On Mon, Sep 28, 2009 at 12:22:56PM -0400, Mel Chua wrote:
> >> >> And yep. I think that keeping track of other Sugar liveUSB
> >> >> implementations is going to help this, because that way we can keep
> >> >> track of naming. ("Sugar liveUSB implementations" is a much better
> >> >> term than "SoaS spins," which was the term I was using because I
> >> >> couldn't think of any others.)
> >> >
> >> > Perhaps "Sugar live images" would be better?  They're not just for USB
> >> > devices.
> >> >
> >> > Actually, the only distinguishing factor I can see (besides being
> >> > talked about far more than they're tested ;)) is that they were
> >> > originally designed to run from read-only media but now cannot.
> >>
> >> I see two other possible common factors:
> >>
> >> 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).
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).

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
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 sound doesn't work it's not that big a deal.

sound autodetection is not related to removable / non-removable
installation media.

> 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.

> My impression is that networking is important/easy enough that it
> tends to work although wireless can still be problematic.

Right - so it's the same.

> >> 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.

> Portable/Live Linux systems tend to have different security models.

Fair enough - though with Sugar it's not an issue since it's designed
to work with rainbow (and as far as rainbow doesn't work, everyone
talks about deploying it passwordless anyway).

> > Could be - though to me "portable" and "transportable" are saying the
> > same thing.
> 
> For me, portable has some connotations of being less capable.  But
> either term will work for me.

Ok.

> Bill Bogstad

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/soas/attachments/20090929/804494f8/attachment.pgp