Suggestion to Klaus Knopper: release combined 32- and 64-bit base for remastering

@patelbhavesh: thanks for the pointer to Debian Live. I got Debian 7.3 up and running and installed the live-build tools and made a Wheezy iive with just the LXDE desktop and no extra applications. ISO is 745 MiB, and I don't even have a browser in it. It will take a lot of work to slim it down to fit on a 700 MiB CD. Klaus Knopper has already made a fine job of of trimming and slimming down a live Wheezy, and that is why I would like to start with a basic Knoppix.

Fun fact: I have tried a full remaster of a Knoppix 7.2.0 CD. All I did was remove Gimp. The compressed cloop was larger than the original one, even though I tried all the settings to get the smallest possible cloop. Klaus knows a few tricks allright !

Quote:

---

Originally Posted by fredvej

All I did was remove Gimp. The compressed cloop was larger than the original one....

---

Your new compressed loop probably contains a full complement of Gimp files
plus a few new files showing how to ignore thes files as if they were gone.

You need also to release memory previously assigned to Gimp files to have the effect your want.

I think this could be a very productive thread.

My take on current Knoppix offerings:

Adapting something like the Porteus approach of building a Linux system on
the fly from an assortment of individually pre-selected overlay additions
does look like a reasonable request from this forum's standpoint.

From Klaus K's standpoint, end products of LiveCD and LiveDVD from two
carefully selected, but not individually selectable overlay definitions will
continue to make sense as 'deliverables' in his associations with CeBIT and
LinuxMagazin.

Knoppix is usually configured to use up to eight overlays; one for the LiveCD,
two for the LiveDVD and up to six more for those who care to define them.
Moreover, the current limit of eight may be expanded if the Linux is re-compiled
to define a larger number of cloops. However, there is a trade-off in storage
efficiency in that the more cloops are provided-for, the more memory space may
be assigned but not utilized, if the cloops are not actually used.

Porteus uses squashfs rather than cloops to prepare and handle the overlays.
A squashfs approach may simplify the arrangement of persistence, but offers
very little performance advantage in speed or compaction. Klaus K is the
current maintainer of cloop definition, so trading cloops for squashfs may
not simplify his life any.

Some of us do 99% of our Linux work using a LiveUSB rather than a LiveCD or
LiveDVD. I generally make a Knoppix LiveCD and from that my Knoppix LiveUSB,
but one might alternatively use a PenDrive program to make a LiveUSB directly
from a Knoppix iso.

The LiveUSB is faster and may be less restrictive in size than
either of the CD or DVD media. Optical drives are not even part of some
netbook or low-end laptops; such units usually have USB and/or memory card
readers.

The majority of computers likely to use Knoppix will be 32-bit or 64-bit.
The majority of commonly used software will not utilize or show much
improvement in its operation even if all its 64-bit-programmed potential
is utilized. Where this is not the case is an exceptional case, not the norm.

My suggestion:

Therefor, I would like to suggest, for starters, that we consider a third
alternative standard product, a new 32-bit Baseline LiveCD iso defined as follows:
Same as the current 32-bit LiveCD iso, except leave out IceWeasel, LibreOffice
and Gimp. In the LiveCDs definition of how to make a LiveUSB,
add a Knoppix menu item to the LiveUSB menu with which to prepare
additional LiveUSB overlays. Leave the cloop limitation as it is. Add an
additional Knoppix cheatcode definition to allow a selection of user-defined
overlays at boot time.

I think such a suggestion may be within reason for Klaus K to consider.
It would be nice also to be able to make the initial LiveUSB without an intermediate
LiveCD, but I'll yield on that for now.

I fully endorse what Utu suggests. Live USB is the first step to follow. Minimal basic Live knoppix. Pre-selected overlay additions: game, programming, education, and so on to "expand the capabilities" for those who need.Thanks

Quote:

---

Originally Posted by Blacksimon

...Pre-selected overlay additions: game, programming, education, and so on to "expand the capabilities" for those who need....

---

I know this is a nice feature of Porteus, but if Knoppix were to have its own capability to generate overlays, then everyone might define their own overlays. For example, If I had a Baseline LiveCD as I defined, then with Synaptic I'd temporarily add IceWeasel, LibreOffice, and Geany and a few fiddleware settings temporarily to my persistence file and then use the new added capability to roll this into my own unique Knoppix1 overlay.

I am specifically NOT advocating pre-selected sets of overlays, but rather the ablilty to make our own unique overlays from a common,
minimalist Baseline. Agreeing on a Baseline is in itself a hard enough task, there being infinite possibilities.

I appreciate the thought that has gone into this, and I would add my voice to those who see the utility of a minimalist knoppix. My only additional suggestion is to modularize the desktop as well.

The real value inherent in knoppix lends itself to this kind of modularity (squashfs vs cloop notwithstanding). What is the memory overhead for adding cloops?

As far as standard vs roll-your-own modules, I think that those who made cleverly implemented RYO modules could make them available to others. In other words the best of both (and satisfying the anarchist in me, no rules).

Quote:

---

Originally Posted by dwstarke

...cleverly implemented RYO modules..

---

If we have Synaptic and a mkisofs utility in the Baseline, we can make our own unique modules.
We needn't ask Klaus K to do what we can easily do ourselves.

In regards to the overhead for increase in the number of cloops, I've heard the problem is
that if eight aren't enough, the next choice is sixteen. If so, whatever the overhead is now,
it doubles this overhead if you want more cloops than eight.

First, I really can't understand why someone should seriously want to confine themselves to CD size distro with 64 bits nowadays, other than for server or forensic purposes. If remastering is the issue, I can ensure you that DVD remastering is a breeze resource-wise, using adequate hardware. You can even perform it in a VM.
It there were a knxbootstrap package, derivative of debootstrap, to create a bootstrap mini-Knoppix, it might have made a little more sense to create 64 bits CD ISOs, but there isn't, and will probably not be for a while - unless someone around takes up the task.

Second, if running 64-bits kernel is the goal, we already have it. For instance, I'm running several 1-2MB instances of Windows and Linux under vmware simultaneously in Knoppix, on a laptop with 16 GB memory, cheatcode knoppix64. As far as 32/64 hybrids systems go, I think Knoppix is close to optimal as it is. I never run with 32 bits kernel unless I am forced to do it. I can understand very well why KK has chosen this route, rather than working with two separate versions of Knoppix.

Third, thinking a lot about cloop details is a dead alley. Several of us have routinely remastered Knoppix with squashfs, and there is really no big deal to drop cloop altogether. But, again, I think KK has his good reasons for sticking to it - which does not force us to follow suit. The main reason I am running from a (second in row) cloop remastering now, is convenience: I haven't taken the time to patch the current minirt.gz for squashfs use.

Fourth, there are several possibilities booting the 64 bits kernel and chrooting into a pure 64 bits environment. I think this is the easiest way to pure 64 bits today.

Fifth, no one stops you from creating a 64 bits version yourself. I did it with Knoppix 6.4.4, by mix'n match with standard Debian, and it works. Compressed size increased some 10-20% with 64-bits package versions. Booting with 64-bits busybox gave some strange "features" though. My main reason for not following this up, is that Knoppix 7.x and the corresponding Debian had grown further apart, and KKs hybrid 32/64 offering provides most of what I normally need.

Sixth, if you compare the init in Knoppix and (for example) Debian live, you willl see that there are several differences in approach, and I personally far prefer KKs way. As far as I can see, also Kanotix has drifted quite far away from Knoppix. Also, putting together a distro like Knoppix is something different from just gathering packages from here and there and lump them together in some kind of tarball. Furthermore, different overlays are very likely to start producing conflicts, which is one reason why I have stuck to the single 4GB cloop/squashfs model, and have rather performed another remastering than creating overlays. But that's me, YMMV.

Seventh, the more bytecode is used in the applications, the less is often gained by compressing. I have started to take Java things out of the compressed image because they consist largely of jars that are already adequately compressed.

All these remarks nothwithstanding, I think that sooner or later, there should be a pure 64-bits companion version to KKs standard Knoppix - and I think 2014 may well be the year to carry out such a project. I don't expect KK to take much initiative in this direction himself, but he has been in no way hostile inthe past :) I don't think multiple overlays is such a grand idea, but sticking for now to ca 4 GB for compressed images, two levels may be practical, with a common 4GB basis, rather similar to the current DVD version, and then different overlays. Being able to distribute on a DVD/ISO might be preferable, and I think most would not need more than one overlay in addition to the basis. Further overlays might then be created by the user as needed, for example the way utu uses them.

utu, I agree that a 32 bit basic Knoppix without IceWeasel, LibreOffice and Gimp would be a very useful base for customizing, and hopefully it won't cost Klaus Knopper much extra work. We must keep his build proces in mind, it's not divided into stages as I suggested.

Regarding adding software on the fly, have you experimented with the update feature as described in knoppix-cheatcodes.txt ? "If you place an update*.zip or update*tar.gz file on the medium holding the KNOPPIX data, it will be unpacked onto the overlayed filesystem before starting "init", thus allowing quick reconfiguration of the system."

@fredvej
1. Thanks, Freddy, for starting this nice thread. We're seeing a nice interesting
interaction among forum members here as a result.
2. I've used the two update features on occasion in the past as a means of preserving
my persistence file material which I am in the habit of catasrophically over-writing
on occasion. However, it is so easy to package, compact and save a snapshot of
persistence with a mkisofs utility, I currently prefer that approach.

@capricorny
1. Greetings, nice to hear from you. I hope you'll post more details of just how you
manage your Knoppix re-masterings.
2. My op ed earlier was slanted toward asking a minimum of Klaus K, trying to stay
within what I think his own framework for producing Knoppix might be.
Other Linux distros have their own minimal configuration from which to build up one's
own tailor-made system. KK could easily dump a 'baseline' iso with very little
additional effort.
3. I think you and I may represent two extremes in using Knoppix. I prefer a mininal
configuration, and like to build up my small Knoppix from overlays. You seem to represent
the 'power user' and can and do tackle larger modifications of Knoppix to get what you
want. One size to begin or end with clearly wont suit both of us.
4. I concur that Klaus K would much prefer a good working example of code for any
suggested improvement of Knoppix. Gilles' contributions to init show how effective this
approach can be.