Actually, I would partially disagree. A system has many lines of development (subsystems) which interact so as to compose a system that just works: two examples of such subsystems might include an automated update system and a manual administrative system. However, when all of these subsystems themselves depend on one and only one component, BLAH, then the system as a whole is super-critical. That’s because none of the subsystems, to include those able to effectuate repair and recovery, will work if the single component BLAH which underlies them all happens to break. Such a system is an accident waiting to happen. When the accident does happen, it takes the operational form of Catch-22s. An example of one of these catch-22s is that you you can’t update your way out of having a bad, broken BLAH to having a good, fixed BLAH when BLAH s required for all updates to happen to begin with. The biggest Catch-22 is when ROOT becomes inaccessible, because it, too, depends on the self-same, broken component BLAH: you can’t fix BLAH if root is inaccessible and BLAH is the very reason that root is inaccessable. The solution is not to fix the one super-critical component BLAH and only that. That only achieves mission stability. The system needs to have redundancy in order to achieve overall, system stability. It needs more redundent BLAHS, more species to the ecosystem, ones which do not exhibit mutual dependencies, mutual recursions or over-dependence on single, super-critical components. In this case, the system then can at least be repaired and recovered in-house, and using the remaining and working subsystems, rather than having to jailbreak into it and hack it. A fully-blown system, with 45,000 files, is a monster to hack. There aren’t that many gurus. And I am not one of them. |