Basically gzip. The cloop-device (compressing loopback, a filesystem-independent block decompression kernel module) uses zlib. Some experiments with bzip2 lead to slightly smaller size, but cause unacceptable slow decompression. For gzip, the overall reading speed from CD is even faster than using an uncompressed stream, most likely because of less head movements.
How are you able to have Knoppix recognize all the drives without a preconfigured FSTAB?
In the current version, I use fdisk -l to parse the disks listed in /proc/partitions, which unfortunately doesnít work if the drive isnít partitioned correctly.
I'm working on a more reliable version that tries to find out the actual filesystem type used by file -s followed by a read-only test-mounting of each recognized partition. Also, Partitions will be automatically rescanned in one of the next releases when you plug in a USB memory stick or similar changeable storage media.
It seems you release an update every couple of weeks, yet the version number doesn't change, why is that?
I found no reason to change the version number when just "minor" changes like software updates or occasional new smaller features are made. More important (especially for the changelog) is the build date, which represents the "snapshot date" for the Debian packages included.
I'm usually releasing a new major version at LinuxTag every year. Minor version number updates are also possible, but only if something changes significantly (maybe for inclusion of KDE 3.1).
Given the phenomenal success rate in detecting hardware have any of the distributions approached you about helping them with hardware detection?
How does the Knoppix boot process differ from a conventional hard drive based Linux install?
A Ramdisk is used as root file system. The first part consists in actually identifying the CD-Rom (loading SCSI drivers) where the CD is located, and mounting the compressed loopback file KNOPPIX/KNOPPIX. Then a script is run for identifying all supported hardware components, generating links in /dev and config files. After that, the boot process does not differ much from a harddisk-installed version.
Can you explain the Terminal Server/PXE aspect of Knoppix, and what your goal is with this project?
The goal is to use one computer as server for a whole classroom of client PCs that can boot remotely from that server without the hassle of configuring a lot of services manually (DHCP, TFTP, NFS, BIND, SQUID, IP-Masquerading are configured semi-automatically).
You could use this for teaching GNU/Linux applications, demonstrations or simply an ad-hoc internet cafe installation.
Do you have any plans to extend Knoppix to use DVD or Mt Rainer?
Not yet. Most users have only a CD burner (at maximum), and I can't maintain different versions of the CD in parallel.
Based on your experience developing Knoppix, what parts of Linux need improvement?
The support of proprietary and non-documented hardware (winmodems, onboard soundchips, exotic graphics cards...) is naturally bad, but there is not much that the kernel developers can do about this, other than sending complaints to the vendors who don't give away sufficient technical specifications. The Linux kernel offers a wide range of workarounds for strange hardware though, which is very practical for Knoppix, especially concerning the "cheatcodes" for making it work on otherwise problematic computers.
From the GNU side of GNU/Linux, it would be nice if developers could agree more on which library versions are stable or at least tested enough to be the base for their software packages. Sometimes I have to include 3-4 versions of the same library in order to avoid conflicts. Of course this also results from the fact that large parts of the software included on Knoppix are relatively new and need library versions that are undergoing heavy development.