[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: cdlinux


I think the following may be interesting to some of you, so here it
is. a humble littlt project. ;)

* cdlinux is supposed to be debian running on live! cdroms, but it
should be generic enough, and keep the code for its specific purposes
to the minimum. and it should be capable to be installed to harddisks,
and running there thereafter.

* cdlinux is also supposed to provide a easy chroot alike environment
for debian developers to build their packages for different releases,
aka testing/stable/unstable. This is not a problem for some of you
have spare computers and/or nice backup utilities. but to alot of
developers, building a chroot environment is difficult and tiresome,
and to some packages, to test them may be dangerous(?) OTOH, cdlinux
could provide a consistent platform to do package maintaining. at
least I hope so. ;)

* cdlinux may also be capable to provide some debian users fancier and
easier installation methods. the difficult point on providing fancier
and easier installation to our users is that the resources on the
install time is very limited. while this is always true for netinstall
and floppy install, it's not true for cdrom install. what if you have
a running system by hand Ie cdlinux, when you begin to install debian
from cdrom into harddisk? why keep packages as static .deb format on
cdrom instead of extract them into a runnable state if we're able to
do so? why do we want busybox if we could get a bash running in a
combination of read-only cdrom and read-write ramdisks? after all you
don't need to write to the bash executable, so it's perfect to put it
on the read-only cdrom. ;)

the above is the supposed benefits of cdlinux, the below is some
design docu. i welcome critics and suggestions. and oh, please! ;)

* cdlinux needs a version of linuxrc which is capable to get the cdrom
device and detect the cdlinux cdroms, (BTW, this linuxrc is largely
there, see cdlinux.sourceforge.net, BTW^2, if we get enough developers
interested, i may request to move unto cvs.debian.org to save you from
registering on sourceforge.net ;) and the linuxrc will just do that,
nothing more, and won't bother the users even one single dialog. it
shouldn't. we don't need a user interface in a crippled environment,
do we? ;)

** I stolen the linuxrc from demolinux who in turn got that from a
early version of SuSE. credits ... ;)

* linuxrc will also setup a ramdisk as read-write root directory tree,
and setup mount individual fs trees out of cdrom, details in
discussion. i currently use a mixture of cramfs images and isofs
images, this certainly is a very bad idea, it prevent easy building of
cdlinux cdroms.

* a better solution is layered filesystem, Ie ramdisk on top of isofs,
to provide read-write transparency. this is certainly doable. ;)

* after the above, Ie linuxrc and probablly layered fs, here comes the
rescue of debconf. ;) we suppose packages would be runnable after 1.
extraction and optionally 2. ask user some questions through debconf.
in the senario of cdlinux, we will have step 1. done in prior. and
will keep step 2 deferred 'till users boot cdlinux. of cource this is
over simplification, but it illustrate the overall scene as 1. doable
2. doable in a generic way. and 3. also a chance to improve debconf
performance in debian. ;)

* after this cdlinux would be runnable from live! cd. now we see how
the install to harddisk works? it's merely dpkg-repack|dpkg -i without
of the overhaed. and move the debconf answers to harddisk etc. ;)

Any ideas would be appreciated! Thanks!
http://dim.sourceforge.net ............... Debian Chinese Input Method
http://njlug.sourceforge.net ............ NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ........... Debian running on Live! CDs
http://people.debian.org/~zw ...................... XEmacs Screenshots

Reply to: