Merging Live and Install CDs

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Matt Zimmerman wrote:
> On Fri, Feb 11, 2005 at 11:38:30PM +0000, Colin Watson wrote:
> 
> 
>>I believe there are also people working on a live CD installer, but this
>>will not supersede the install CD, which is simply more appropriate for
>>many use cases.
> 
> 

I'll try to compare this to the
pseudo-debs/partial-debs/JigDebs/whatever that I mentioned earlier.

> I've been thinking about this quite a bit recently.  A casper-based
> filesystem-copying install would have a number of compelling advantages:
> 
> - Very fast

JigDebs would likely be slower than even a normal install.

> - Very simple

JigDebs would be used probably by passing the install debs through a
program that stripped them down based on a path, so generating the
LiveCD would be simple.  Actually using them would be identical to using
regular debs.

> - Rich UI capability for a graphical installation process
> - Easy access to online help resources via multitasking
> - One CD does it all (install, demo, recovery)

These 3 match.

> 
> And of course some disadvantages as well:
> 
> - Somewhat increased memory requirements compared to the traditional
>   installer (though very close to those of the installed system)

JigDebs wouldn't need more memory; but they'd need some extra space.
I'd predict 20-50M, but I don't know really.  I'm basing this off the
assumption that the average JigDeb is going to be 20-50k; and that
there's about 1000 debs or less on an install CD.

> - Could not be used for upgrades

JigDebs could be.

> - Would not be suitable for WAN installs

JigDebs would be useful for standard installations.  WAN installs, I
don't know what you mean; however, reconstructing debs from JigDebs is
theoretically possible.

Signing reconstructed debs isn't possible without taking extra steps
that could be very penalizing, such as leaving enough information to
reconstruct a byte-for-byte copy of the original deb.  It's not worth
the effort; the JigDeb is signed, the hashes of the files used are
stored in the JigDeb, the CD is from a trusted source anyway.

Providing a byte-for-byte copy is also not possible, since the original
deb would be compressed, and the files would be uncompressed.  The
stream could not be recreated without VERY intense and creative and
FRAGILE programming.

> - May or may not be suitable for LAN installs (I'm keen to try it)

JigDebs could be reconstructed to regular debs; and the installation is
essentially like a normal install.  I'm assuming by LAN installs you
mean to say PXE booting, in which case the PXE server would be able to
supply an installation program which could request debs, while the
server would translate those requests by collapsing the original jigdebs
into full debs.

> - Remastering is more complex

Remastering is only as complex with JigDebs as with a normal LiveCD,
plus one extra step to fetch all used debs and strip them down to make
JigDebs, transforming the CD from a LiveCD to a do-it-all.


To recap, here's the JigDeb advantages:

 - Very simple
 - Available UI for graphical installations
 - Do-it-all CD (Demo, install, rescue)
 - Minimal extra space usage
 - Suitable for upgrades
 - As suitable for LAN installations as using regular debs would be
 - Simple to remaster
 - Simple to develope
 - Simple to use -- single script could fetch all needed debs upon
building a LiveCD and strip them down
 - The basic design of normal debs is untouched, so the new apt would be
compatible with the old apt; new and old full debs would be usable by
both versions of apt.  Only jigdebs would require the new version.

And disadvantages:

 - Requires somebody to put forth the manpower to code this
 - Likely to be slower, though not necessarily noticably slower
 - Full debs cannot be regenerated signed

And a work-around:

 - The PXE server for LAN installs could authenticate its connections
using a traded GPG public key randomly generated for the boot session.
Thus, full debs could be signed using the PXE server's key, giving some
proper level of security against simple man-in-the-middle attacks.

> 
> While I must agree that it could not supersede the installation CD, there is
> great promise in it.

I would hope the JigDeb design would be robust enough to replace the
Installation CD.  Replacing the install CD has several advantages:

 - Ease up space usage on the mirrors significantly by halving the
number of CD images
 - Ease up maintainer overhead -- one CD to maintain per arch
 - Offer the user a more powerful installation media by providing both
reinstallation and emergency rescue
 - Offer the user a pre-installation experience by providing a demo
right on the installation CD, potentially halving new users' download
time and saving some plastic trees
 - Offer the user a productivity suite (openoffice, gnome, firefox, some
games) to occupy him for the half hour it takes to install

>  If I had to choose one Ubuntu CD to give to everyone,
> it would be a combo install+live CD, hands down.

I believe that this is a realistic goal and that it can be reached in a
robust manner.  I believe that for the better good of the user
experience, effort should be put forth to reach that goal in the most
direct manner.  I also believe that the most direct and robust solutions
may be easier and more durable than other options such as filesystem
cloning.

>  For DVD, of course, we can
> have the best of both worlds, but CD will be with us for some time yet
> (especially as a download option).
> 

The DVD should be avoided until two conditions are met:

 - The average user has a 30mbit/s or higher connection; current
connections are 5mbit/s and DVDs are about 4GiB.  We should shoot for
the same download timeframe.
 - DVD burners are an ubiquitous accessory

I believe that 1 gig CDs would have put us well into the "Everything the
user would need, including all the perks" area.  We try to cram into 700
megs now, but usually we get very close.  Even when DVDs are common, a
small but useful distribution would be more ideal than a distribution
which abuses the large amount of space simply because it no longer has
to solve problems in other ways.

> I fully intend to make this an option for Hoary+1, time and resources
> allowing.
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDYRUhDd4aOud5P8RAtJXAJ99PCREBWNEhm4d2v/QW0nmJL4VRACcC37P
dRafp/SUTCsEVDgYZxDEkVo=
=SpnB
-----END PGP SIGNATURE-----