Dynebolic Choices

Dynebolic version: 1.1.1

Choice of compressed read-only filesystem

In a running LiveCD system, most of the runtime filetree is a read-only filesystem that is uncompressed on the fly from the CDROM. As well as raising the limit on the filesystem size from 640MB to about 2GB, it contributes greatly to the speed of the system, because the speed at which we can read a CDROM is slow, and the processing time spent on decompressing all data read from the disk is more than repaid by the reduction in the amount of data read.

This is borne out by a comparative study of Linux live CDs: the slowest of them all is the only one that does not use a compressed filesystem. See http://freaknet.org/martin/dynebolic/livecd.html

There are several read-only compressed fileystems available for Linux:

squashfs

Is freely available from http://squashfs.sourceforge.net as a set of patches to the 2.4.19 to 2.4.22 kernels. In dyne:bolic it uncompresses /usr on the fly from an image in a file /squashedfs on the dyne:bolic CDROM.

cramfs

Is included in the standard Linux 2.4.20 kernel at http://kernel.org. It is intended for read-only filesystems in ROM, does not support hard links and timestamps and is limited to 256MB filesystems. This last limit makes it unsuitable for dyne:bolic.

zisofs

Is included in the standard linux 2.4.20 kernel at http://kernel.org. Instead of having the entire compressed filesystem in a single file on the CD, it compresses each individual file within a regular filetree on the CDROM. The compression it attains is inferior to that of squashfs (525MB for /usr instead of 458MB).

cloop device

The cloop device is a generic way to compress any other filesystem. It is like the loopback device used to mount regular files as if they were block devices, but implements gzip-style data decompression on the way. In other LiveCD distributions, cloop is used in conjunction with ISO, ext2 and romfs filesystems.

Klaus Knopper (of Knoppix fame) says:

zisofs is a compressed filesystem, cloop is a compressed block device. Compressed filesystems are slower, because each file has to be uncompressed again in each read, while cloop keeps the uncompressed blocks in the normal block layer filesystem cache. cloop is older, well-tested and filesystem independent.

but this doesn't sound right. Cloop (and loop) present the contents of a regular file as a new block device, so I would think that caching would happen twice:

When the compressed data are read from the medium by the device-specific driver
When the uncompressed data are read from the cloop device

so this would mean that each piece of data may be cached both in compressed and uncompressed form, and re-reading the same data may do one of three things

return it immediately from the top-level (uncompressed) cache,
uncompress it a compressed block in the bottom-level cache, or
read it again from the medium and uncompress it, presumably making cached copies of both the compressed and uncompressed versions.

In a memory-limited system, you would be better off having a single cache, since I can't see cloop being able to put the use of blocks in the two caches (or, rather, the two uses of the single buffer pool) in comunication, for example, to free compressed blocks for which an uncompressed version is cached. In fact, in a memory-limited system, it's better to cache compressed blocks than uncompressed ones, and for dynebolic, good use of RAM is crucial to speed.

Choice of window manager

Windowmaker

Is dynebolic's usual window manager. It is about the last living descentdent of the visionary NextStep.

Fluxbox

Is also there, and you can flip between them. It looks the same to me. Performance benchmarks, anyone? Measurement of memory requirementes?

KDE

Is enormous, and has too strong a look and feel of its own to implement dyne:bolic's simplicity.

GNOME

Sucks and crashes. It's also more resource-hungry than Fluxbox or WindowMaker.

Choice of sound system

OSS

Dyne:bolic uses OSS sound driver modules, the first full set of sound drivers implemented in the linux kernel.

ALSA

Dyne:bolic uses ALSA drivers if it can't find a suitable OSS driver for the current device. Or the other way round, I forget which. The next Linux kernel drops OSS and uses pure ALSA. Enough said.

Enlightenment Sound Daemon (Gnome)

mhearn ( http://www.linuxquestions.org/questions/archive/9/2003/05/1/57017) says:

Eurgh, esound is junk. It's been obsolete for years, unfortunately it does the job just well enough that nobody has built something better (that's portable, jack is a lot better if you only care about linux).

Jack

Is on the list...

Choice of printing system

CUPS

Dyne:bolic uses CUPS.

Martin, Dec 2003 - Jan 2004.