create a forked knoppix - what do you think about this ?

[kl522]

Well, rather than speculating, we can proceed to produce that geek-knoppix. Then Klaus K is free to include or drop any changes in his next upstream release. And, if you look at his communication with Ryumbeke, he can be very positive towards suggestions and modifications. Also, I think the direction of development in 6.X is the opposite of secteric.

My take on some of the main features:
* ext4-support plus, eventually, other non-suppeorted fs in general use.
* Thorough purging of non-essentials, like space-consuming games. Users can install them themselves.
* Addition of a series of packages that are important for some users. My own standard examples: R and some Java packages.
* Maybe addition of some packages/libraries to facilitate the installation of some programs/extensions that are not included.
* Use of squashfs, at least as one version, keeping the cloop tools.
* Tools for setting up for GRUB-booting.
* Backup of persistent store + safe system transfer. (Copying mounted and constantly modified persistent store is not entirely safe, it seems.)
* Remastering tools.
* If possible, some tool for collecting package use statistics - to aid in inclusion/exclusion of packages.

Here we have a list of changes you suggested for a forked version of knoppix. I think it is a good list, as far as changes are concerned. What I am uncertain is whether it is a good idea to create such a fork. Perhaps we should invite some comments first.

[utu]

A number of others have sought to improve Knoppix by creating
custom versions of Knoppix. Not many of these have out-lasted
Klaus-Knopper's-Own. See for example:

http://www.knoppix.net/wiki/Knoppix_Customizations

I think it might be more useful to take Ruymbeke's approach to
suggest just a few specifics to Klaus K himself. It's possible
that Klaus K has his own small cadre of contributors and might
respond favorably to applications to others similarly qualified
and volunteering programming assistance.

The only avenue I know of to do this is to post something on
the Debian-Knoppix mailing list and then to wait patiently for
a response. The Ruymbeke approach I refer to (one of several
attempts, I might add) is at:

http://osdir.com/ml/debian-knoppix/2.../msg00014.html

In any event, good luck on your endeavors.

[Capricorny]

....
The only avenue I know of to do this is to post something on
the Debian-Knoppix mailing list and then to wait patiently for
a response. The Ruymbeke approach I refer to (one of several
attempts, I might add) is at:

http://osdir.com/ml/debian-knoppix/2.../msg00014.html

In any event, good luck on your endeavors.

Why wait? It is much better to implement the ideas, see if they are any good, and then report and eventually discuss afterwards. Negative results are also important, because that provides information on less fruitful ways.

If we make a remastering available for download, the experiences gained from using it would provide very useful information for decisions about directions for development.

[utu]

@ Capricorny

I don't suggest you wait.
Keep doing what you are doing.

I only suggest you try ALSO to involve Klaus K if you can.
And the only way I've seen to do that is via
the Debian-Knoppix developer's mailing list.

I think interaction with Klaus K will enhance your efforts
whatever direction you initially take.

[Capricorny]

@ Capricorny

I don't suggest you wait.
Keep doing what you are doing.

I only suggest you try ALSO to involve Klaus K if you can.
And the only way I've seen to do that is via
the Debian-Knoppix developer's mailing list.

I think interaction with Klaus K will enhance your efforts
whatever direction you initially take.

Sure!
But the crucial thing right now is, that the current Knoppix version is so well made, that it is not necessary to consult with Klaus to implement some further developments. Ext 4 support and squashfs for instance, anyone can simply do it. And even without remastering, I'm already using GRUB to boot poor man's installs. I'm also performing file system check and backup of persistent storage, but only manually. In fact, it is interesting to see how much can be done without knowing special details about Knoppix, just applying standard Linux/Unix methods and tools. It turns out that it is very much, attesting to the well-behavedness of Knoppix.

[Werner P. Schulz]

... why not read the list itself and write to it (after subsribing)?

[Capricorny]

While I am open to the possibility that a fork might turn out to be good for the project as a whole, what I have suggested amount to a direct derivative. It might take a life on its own later, but the actual steps starts with standard Knoppix. And for my own part, I would like to keep it that way for a while.

This is about trying out things and ideas, catering for different needs, developing missing routines, and so on. It has not necessarily much to do with "mainstream Knoppix", it has to do with using the resources in an optimal way for some users. Basically, it is about utilizing the stengths and potentials of free (not solely as in free beer) software. Therefore, I think it may be wiser to discuss on the "official" mailing list after we have worked on this and gained experience. There is not really anything speculative or controversial about my suggestions.

As for squashfs, what may be considered one of the closest relatives of Knoppix, Ubuntu, is using it. And I think its introduction might make the remastering process more robust - and surely simpler. For running off CD/DVD, cloop might possibly have an edge - but how much of total Knoppix use today is that?

I think arguments about short-lived derivatives are quite interesting, in the light of Klaus K effectively forking the whole project himself with the introduction of MicroKnoppix and 6.X. I myself would not have used 5.X-type versions for other than "forensic" purposes today, but on this forum we have seen quite a few longtime users preferring the old ways. The changes brought Knoppix closer to mainstream Linux, as will a change from cloop to squashfs. I have never considered "if it ain't broke, don't fix it" a typical open source-attitude. The attitude as I know it, is rather "If it's broke, fix it, and if it ain't broke, great! Experiment with it."

What may be somewhat controversial, is something underlying this: The idea that "if you want more than this, go for the full Debian install." This has clearly been true in the past, but from my ventures into full installs over the last years, I have quickly returned to Knoppix poor man's installs. Even for simple server use, I find Knoppix-derivatives quite good, but this is something to look more closely into.