#Specification: subsystems / principle ([subsys.cc,1])
All services managed by linuxconf and its modules are organised in subsystems. Subsystems are used for configuration versioning and cluster administration (where a cluster is a group of machine sharing some configuration files). Each config file (or even part of a config file) belong to a sub-system. Subsystems may be archived independantly. A configuration version tells linuxconf how to archive the various subsystems it holds. Two different version may archive all subsystem in the same "family" except for few sub-systems. This mean one can switch between two version and share various configuration file between the two: Changes made to them while working in one version appear in the other. Only the sub-system which are archived differently will change when linuxconf do a version switch.
#Specification: subsystem / switching version ([subsys.cc,581])
When we switch from one configuration version to another, we only work with subsystem that are archived in different family. Subsystems archived in the same family are simply not touched. This means that most of the time, switching from one version to another affects a limit amount of files.
#Specification: subsystems / fine grain / some idea ([subsys.cc,18])
At some point, it might be useful to break sub-systems. For example the apache subsystem is composed of 4 files. One may think that this could be split into 4 sub-systems, which may be archived (and co-administered) separatly. If we do that now, the specification of a version might become endless. One day, we may think of a sub-system as a hierarchic organisation, where the behavior of one file (or sub-file) may be controlled separatly. So far this is not done.