Please report typos and errors you may find to an author (messer at domain eecs.berkeley.edu).
Page 30, heading for Section 2.3.3: Should be “Instrumenting Moore’s Law”.
Page 172, next to last paragraph: It is fair to say “industrial organization is determined to a large degree by the invisible hand of market forces rather than the visible hand of an architect”.
Page 237, Third Example: “Linux uses a FAT32 file system adopted from DOS” should be replaced by “Linux supports the FAT32 file system of DOS, in addition to several of its own”. The statement leaves the impression that FAT32 is the primary or was the original file system of Linux, which it is not.
Page 248, Table 7.5: “versioning” in “Unit of independent deployment and versioning” should be replaced by “Unit of independent deployment, variation, and versioning”. Here we refer to the ability to upgrade a single component in a system to a new version, without the necessity of upgrading the remainder of the system. This is essential lest we constrain the suppliers of all components that have been assembled into the system to offer upgrades in lockstep, something impractical in a diverse component marketplace. We also refer to the ability of a component supplier to simultaneously offer more than one variant of a component, and for different system assemblies to adopt different variants or for a single system to evolve by replacing one variant by another. This is a concrete way to support any variation in needs and requirements across different systems, and a flexible way to accommodate any evolution in requirements for a single system. Legitimate variations in needs across different customers, as well as the legitimate need to accommodate the flexible evolution of needs of a single customer, are both recognized shortcomings of many applications today, and component technology is one promising response.
Page 253 line 4: “created” should be replaced by “instantiation” to avoid leaving the impression that this involves programming. “Instantiation” is a word used by software engineers to denote the replication of a module at run-time, configuring it for its specific context, and linking it together with other modules that have been similarly instantiated. Instantiation is analogous to manufacturing in the material world, whereas creation is analogous to the design of a product in the material world.