--- Jane Dogalt <jdogalt(a)yahoo.com> wrote:
> What would be the most plausible for Kadischi, any ideas?
I think kadischi should be absorbed entirely by anaconda.
Use something like a --output-livecd=foo.iso, and have anaconda create an
internal tmp rootpath directory.
For any livecd configuration, add more steps/screens to the anaconda install.
Actually, I wasn't thinking of this 10 minutes ago when I wrote this, but...
With the above, you could also allow a checkbox on a real native
anaconda(fedora/redhat) install, say "create livecd boot image", which would go
ahead and do a completely normal install on a system, but then leave a bonus
bootable iso, say /root/anaconda-livecd.iso, for the user.
Thus, for the people on this list who have talked about using kadischi to
create deployable read-only livecd's for particular systems (say a particular
dell hardware configuration, to be used as an appliance/kiosk), they could just
do a normal install on one instance of the system, and boom, there is your
Or even, if the system has a cd burner, you could do the install, and burn the
cd right away. Maybe just using temp space on an existing system partition
(vfat even) to generate the install iso.
Of course, thats not very far away from my earlier dogmeat post about using a
generated livecd as a configure/build/test environment for more livecds.
Which has a fair amount of synergy to merging the generic os installer with the
generic livecd, ala mandriva one, and something like a project I did years ago
which just cached("installed") the livecd image to an existing disk
partition(think host vfat).
My hunch is that the recently fired mandrake founders new secret project ulteo
is probably a mix of some of the above. IMO it's the direction to go with
livecds. That and using relayfs/unionfs+distributed network filesystems to do
really incredibly cool stuff :)
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around