[Fedora-livecd-list] Re: goals/status?

[Jane Dogalt]

Ok, I should probably reply to the thread I started.

So it sounds like the basic agreement is that the key 'missing' feature
is an installable livecd, with the install-from-livecd method being so
useful it could potentially replace the standard installation method.

My thoughts on this are-

- I'm personally a little more concerned with the generic robustness of
the livecd as a livecd.  I can see why fedora, playing catchup in the
livecd space, might be tempted to pursue the livecd-installer feature,
but I would remind people that the evolution of other great livecds
started with a robust livecd, and then added the livecd installer
later.  Personally I'd like to see a robust fc6 livecd, without
installer, that gets widely used, just as a livecd first.  I think
there is a lot of development and testing/quality-assurance
infrastructure that needs to be layed down to achieve that.  I think
there is a lot you can do to make a livecd popular that you can't do if
you are trying to make it be the holy-grail installer replacement from
the beginning.  I.e. putting so much emphasis on the installer feature
will bog the project down, because it will take so much work on so many
corner cases to actually make it replace the age-old standard install
method.  (not that it can't be done, but I think it should be done
incrementally, i.e. a robust livecd first, then beta installer that
evolves to installer-replacement quality).

- regarding the actual implementation of the install-from-livecd, I
think that all methods described so far are useful, valid, and should
all be available in the ideal output.  I.e. the livecd generator should
be able to include:

a) a version of anaconda that talks to network repos, and basically
behaves more or less just like anaconda does now on the standard
install cd(it is technically a livecd already...).  I.e. upgrades
matter, full flexibility matters***

***tangent) one thing that has always bugged me (and many others) about
fedora and other linux distros, is that it is not trivial and obvious
how to reconfigure the things configured during install.  I.e. I think
there should be a post install system-config-* for every aspect of
configuration during the install, and that the interface should look
similar enough that users realize it's the same thing.  I.e. the whole
gparted not as good as anaconda partitioning, or the long time it took
to see most of the system-config-* tools which are finally approaching
this ideal.

b) the version of anaconda in (a) should also be able to talk to local
repo, if the livecd generator was told to include a local repo. 
Optionally the local repo could be dynamically generated by repacking
livecd files, to save space  (i.e. keep enough info in the livecd
filesystem to reconstruct the rpms on the fly).

c) an installer that just installs the same system as on the livecd
should exist, which requires no extra repos.  Possibly via rebootless
method I previously outlined, or a simple tarcopy from the mounted
livecd fs, along with partitioning tool and bootloader install tool
(e.g. pilgrim(?)).  Then, the livecd installed system, should be one
which is (a) locked down and smartly configured as a 'base' system (b)
trivially post-install reconfigurable via the system-config-* tools (or
GUI control-panel-alike) into any kind of system that could have been
configured via the traditional installer/configurator(i.e. anaconda).

Anyway, in conclusion, I plan to work on the above sorts of things. 
Much more so in 2 months when my school workload drops by about a
factor of 3.  And hopefully there isn't some radical aspect of this
installer debate which I'm oblivious to because I haven't yet played
with the latest RHEL beta.

later...

-dmc/jdog



 
____________________________________________________________________________________
Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates 
(http://voice.yahoo.com)