This is my first post so I hope to make a good first impression.

So this is not just an idea for a feature, but one which I actually have
partly implemented. I'd appreciate any comments, whether critical or supportive.

I currently have three different projects which I am adapting to a Knoppix environment, and they share common aspects so I thought what the heck, why not create a meta-project which deals specifically with the remastering process.

I call it "KZOPPIX", to distinguish it from the canonical version

(i.e. kNoppix with a twist)

It involves a hack to minirt:/linuxrc to allow the user to specify by name
at boot time which additional optional cloop image modules to add beyond the core KNOPPIX.cloop (I add the extension here, to distinguish between the compressed image and the directory and the distribution...)

e.g. :

At the isolinux boot prompt you would have the option of adding this sort of cheatcode:

knoppix adopt=OPENOFF:MYNOVEL

if you were starting a Knoppix session as a writer, or alternately, to do some quick image processing one might specifiy

knoppix adopt=IMAGES:MYPHOTOS

where the capitilized words represent collections of programs and/or content around a particular theme.

What is the advantage of being able to request OPENOFF.cloop instead of having loaded automatically as KNOPPIX2.cloop as in the CD version?

Partly it reduces points of failure by not loading unused chunks of data. Especially in DVD, one scratch might localize to a single module instead of
destroying the integrity of the entire disk.

Partly it opens the possibility of creating task-specific compressed modules, e.g. SECURITY.cloop which could be maintained, refined and expanded without wondering if there would be room left on the general purpose Knoppix distribution.

It also encourages the creation of a smaller, more minimal essential KNOPPIX.cloop. This core KNOPPIX.cloop would then be supplimented by a KNOPPIX2.cloop which would balance out the swiss-army-knife-wielding jack-of-all-trades which has earned such popularity for Knoppix but which would be easier to set aside when a user decided to do some custom remastering.

As impressive as it is on its own terms, part of the attraction of the Knoppix distribution is the idea of remastering it, and making this easier (i.e. less dependent on deleting deb packages from a chroot ) would make the whole process more accessible.

I am implementing this in a way which does not break existing Knoppix itself, so normal KNOPPIX?.cloop modules are loaded first, always from /dev/cloop0 upward; whilest the optional modules are only loaded on demand, downward from /dev/cloop7.

This way it could be possible to implement this feature with a simple patch to linuxrc which should not effect non-modular Knoppix, and allow both systems being tested and refined side by side while we figure it out the details.

If you are reading this on line you might want to take a look at the .diff of what I have done so far by looking at

http://zyqote.com/Linux/distrib/Kzop...rc-testrc.diff

while the entire rc script is at

http://zyqote.com/Linux/dstrib/Kzopp...uxrc-testrc23k

Sorry for being so verbose, but I've been thinking about this for a good bit, and it is hard to winnow down the features and afterthoughts into the nugget of the essential idea.

Any guidance you could offer will be carefully considered.