The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Shane) writes: > Which of course made the whole thing too complex. Maybe we need to make > it simpler ... other posts in this thread: http://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation http://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation http://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation http://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation part of the complexity issue is possible number of things and/or interactions that have to be managed. it is one of the reasons for modular code. it also one of the reasons for hierarchical management infrastructure and recommendations about "span of control" ... ideal number of direct reports is supposedly seven. fully-meshed interaction complexity is something like N-factorial (i.e. 7! is already 5040). when were were consulting with small client/server company on the original payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway one of the things that we were doing was making the whole gateway operation redundant, including multiple links into strategic places in the internet backbone ... and planning on advertising (alternate) routes in cases of faults. It was in this time-frame that internet backbone transitioned to hierarchical routing ... in attempting to deal with some of the massive scaling complexity issues. As a result, we had to convert to multiple A-record strategy (for alternate paths) as opposed to strategy advertising routes. recent post http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip in the previous post http://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation I had enormously increased the complexity by creating an environment were the particular order of any set of (assembler) instructions, any place the kernel might have secondary effects on other things in the kernel, not only have to take into account individual instruction operation and the purely sequential flow ... but there might be (non-obvious) secondary effects based possibly on the order that things were performed. In the early 80s, I had done a dump analysis tool http://www.garlic.com/~lynn/subtopic.html#dumprx recent reference http://www.garlic.com/~lynn/2007i.html#30 John W. Backus, 82, Fortran developer, dies which was never released as a product, but eventually was in use at nearly all the internal datacenters as well as being used by nearly all the PSRs that were involved in diagnosing (vm) failures kinds at customer shops. One of the things that I studied was large number of system failures looking for familiar and/or common signatures ... and writting automatic diagnostic processes that looked for numerous, identifiable failure characteristics. One such problem, somewhat unique to assembler is the additional burden/complexity that is placed on the programmer for managing register contents. A failure mode that I found to occur quite frequently in kernel assembler code was register contents were not as expected ... possibly because of logic flow taking a particular anomolous path. Higher level languages tend to automate that area of complexity (register) management for the programmer ... and failures due to incorrect register contents occur significantly less frequently. This analysis was one of my motivations behind helping instigate a operating system rewrite project ... with an objective that included significantly reducing complexity (and possibility for failures). some recent references to the operating system rewrite project (which eventually acquired way to much attention, eventually imploding ... somewhat analogous to a "mini" FS failure). misc. recent references to the old rewrite effort: http://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#24 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
