What is good practice for understanding a system? What is the point of understanding a system? How and when does that understanding become outdated? These questions are relevant to system documentation - our topic. This article seeks to directly answer each of these in turn.

Upgrading anything in Gentoo is quite different better architected than the rest of Linux world. One of those is the concept of a profile:

A profile is a set of configuration files, stored in a subdirectory of /usr/portage/profiles, that describe things such as the ebuilds that are considered system packages, the default USE flags, the default mapping for virtual packages, and the architecture on which the system is running.

The profile in use is determined by the symbolic link /etc/make.profile, which points to a subdirectory of /usr/portage/profiles which holds the profile files. For instance, the default x86 2005.0 profile can be found at /usr/portage/profiles/default-linux/x86/2005.0. The files in the parent directories are part of the profile as well (and are therefore shared by different subprofiles). This is why we call these cascaded profiles.

Clients experience me as technology agnostic - but as Microsoft is leading the Web Services pack - I tend to look for projects with a Redmond link. The last few months though my normally Microsoft-centered world has been time-sharing with open-source R&D. Specifically I have been making some cool stuff on the Gentoo distro with Jakarta Struts.

The first thing I did of course was to get a TDD environment in place. That turned out to be much more difficult than it should have been. You know a process needs improvement when you spend hours trying to fix a problem, only to discover it's a 2-second fix that could have been avoided. When the environment was finally ready I was left thinking: how would a developer avoid the pitfalls I experienced? All the grandiose ideas boiled down to one thing: software - especially complex system software - needs to be self-guiding, not simply self-documenting.