dCore Concepts

dCore, like Tiny Core, uses standard technologies common to all Linux distributions in an ingenious way. A layman's understanding of these concepts helps understand the necessary steps for setting-up and managing a dCore installation. This simplified explanation cuts some technical corners and is meant to outline Tiny Core Linux to new users.

To operate a modern computer, one needs an operating system,in our case Linux. More precisely, we use the Linux kernel but that is not all it takes. The kernel operates your computer, that is it manages the hardware components including RAM, video, network, input devices like keyboard or mouse, hard-disks, USB- and other interfaces etc. Furthermore, it keeps an eye on files, users and permissions (and of course does a lot more work, too).

Simply put, the kernel is the first program running on a computer (neglecting BIOS/EFI and boot-loader). It does not do much on its own; instead it provides a platform for running user space programs. After the initial boot phase which makes the kernel run, control usually is handed over to the so-called init-process ('/sbin/init') which calls the individual init-scripts.

As init-scripts are shell scripts, they need a shell to run their commands. So the init-process must launch a shell program and make necessary tools available (typically some of GNU coreutils like e.g. cp, rm, md5sum etc. plus some more like find, grep, sed etc.). These utilities are usually stored as single executables on hard-disk (under '/bin/') and loaded from there when needed.

The initial RAM disk (initrd) steps in to close a gap between the kernel and files on hard-disks. The basic difficulty lies in the fact that the kernel may need drivers to access special file systems. If these drivers lie on such a file system themselves there would be no way of accessing them. Such situation typically arise with encrypted file systems.

The initrd (or more precisely initramfs) contains an archive of a basic root file system. The kernel un-packs this archive in RAM (hence the name) and mounts it as its first root system. From there it runs the init-on-initrd process which can load necessary drivers etc. before the real root file system can be mounted from hard disk. After that the un-packed initrd can be cleared from RAM and the “real” init-process takes over.

dCore is said to run from RAM which means that it does not leave the root file system loaded from the initrd. This avoids loading executables from hard-disks and makes the system run much faster. It necessitates, however, some restrictions in memory usage as one cannot simply dump the full of a regular desktop installation into an initrd. Furthermore, the initrd imposes a crucial restriction by its being read-only by design. (See below about how dCore overcomes this.)

There are various degrees of frugality, and *Core certainly shines. Other notable examples include the installers of most Linux distributions.

Due to its very frugal nature, dCore makes use of BusyBox to provide shell and system tools. The shell provided by BusyBox is Ash (Almquist shell). It is “virtually” POSIX-compatible does not provide all the extras of other shells like Bash or Dash.

> Return to the dCore Wiki Welcome page

Running from RAM yields some interesting consequences which mostly revolve about the fact that the root file system used is not only minimal but also ephemeral in the sense that any change to it will be only written to RAM but not back to the initrd archive on disk.

dCore needs two files to run, namely the Linux kernel and the initrd. Both files can be loaded from arbitrary file systems, most notably FAT32 commonly used on USB-sticks. The file systems does not need to support the Linux file system permissions.

At every boot the root system is in its pristine initial state. So there is no way of inadvertently breaking the system by mis-configuring any system files (but cf. below).

Picture yourself, or somebody else for that matter, issueing the command sudo mv ./* ~/data/ but omitting the tiny dot by a lapse of concentration. Sure enough, you will get an interesting collection of data in that folder, there will be error messages about Linux' fundamental inability of moving '/proc/', '/sys/' and maybe some more and, to round off the whole snafu, no further command will succeed and you won't even be recognized as valid system user any more.

Time to re-install from scratch on any regular operating system, probably. With dCore you simply shut off the system (magic SysRq should still work, although your keyboard layout might be messed up as well) and re-boot. Nothing more is left to do other than cleaning out your home directory.

As the root file system is loaded from the initrd there is no other way to influence early startup options than to specify them as boot parameters (e.g. black-listing kernel modules).

It is clear that a 10+ MB root file system does not allow for great leaps by itself. So there must be a way to allow for additional resources to be added, in order to supply user space software like X11, web browser etc. In the traditional way this is done by supplying several files (executables, libraries etc.) scattered over a file system. There may be dependencies among the applications which are resolved by having several programs installed in parallel.

dCore does things differently by providing software in form of extensions. Simply put, an extension is an archive containing all needed files the same way an initrd contains a complete root file system. The archive (of type .sce which basically is a SquashFS) is created by importing the necessary files from external (Debian-type) repositories. Thus any extension is provided as a single archive file under 'tce/sce/'.

Extensions can be “loaded” which basically means mounting the archive read-only as overlay into the root file system to provide the desired application. Unlike for the initrd, the loading does not happen in RAM and may be done on demand as well as on boot. Since extensions are loaded individually, they must, a priori, be fully self-contained, resolving all dependencies on their own. This makes extensions rather big but has the advantage, again, that any application is loaded in its pristine initial state. Furthermore, dCore does support dependencies among extensions.

A pristine system state at boot is fine but configuring the same things over and over again does eventually get tiresome. So there must be a mechanism of providing persistence in configuration files. Indeed, one can specify a list of files and directories to be saved to disk in a text file (namely '/opt/.filetool.lst'). The files are saved in an archive (namely 'tce/mydata.tgz') and unpacked by the init process to over-write the respective files in the root file system. Similar for the home directory.

The '/home' and '/opt' directories can be included in the persistent storage or also put somewhere on a regular file system to make it persistent. The latter avoids (de-)compressing the full home folder at every bootup or shutdown.

> Return to the dCore Wiki Welcome page