Awesome analysis, I have added it to my favorites list. Around 1990 or so when I was in the kernel group at Sun and a team had just embarked on the multi-processor kernel work that would later result in the 'interrupts as threads'[1] paper. During that time there was an epic thread on email which was something like "What the F*ck does load average mean on an MP system?" (no doubt I have a copy on an unreadable quarter inch tape somewhere :-(). If it helps, the exact same pivot point was identified, which is this, does 'load average' mean the load on the CPU or the load on the system. While there were supporters in the 'system' camp the traditionalists carried the day with "We can't change the definition on existing customers, all of their shell scripts would break!" or something to that effect. Basically, the response was if we were to change it, we would have to call it something different to maintain a commitment to the principle of least surprise. This has never been an issue for Linux :-).
As a "systems" guy I am always interested in how balanced the system is, which is to say that I am always trying to figure out what the slowest part of my system is and insuring that it is within some small epsilon of the other parts. If you do that, then system load is linear with workload almost regardless of task composition. So disk heavy processes load the "system" as much as "compute heavy" processes and "memory heavy" or "network heavy." In an imaginary world you could decompose a system into 'resource units' and then optimize it for a particular workload.
All you old farts (TM) need to get these freaking quarter inch tapes pushed up to some glacier S3 bucket or sum=such bucket before you kick said bucket...
I'm serious. C'mon, don't steal from the future what you actually did in the past to make the present the reality of today!!
Its all about the context though :-). One of the things the Computer History Museum has done a good job of is capturing a lot of the historical underpinnings. But while its interesting, in a "wow, isn't that interesting" sort of way that rail road track gauge is the same as cart ruts which are the same as roman chariot widths (not exactly: http://www.snopes.com/history/american/gauge.asp)
Much of this stuff was fairly constrained by the choices of the time, and as such the information generally ages poorly.
The usefulness of the info may age poorly.. but the historical context won't
Else we end up in a tech situation far in the future where the world looks in the mirror on acid and says "how the fuck did we get here?" - and the tapes provide no answers
Btw, just last weekend I was harvesting 100 year old railroad spikes from a western timber company rail in Sonora because of the context of historical significance - not because I plan to lay a new track...
I wonder if Illumos / SmartOS and OpenIndiana continued with the principle of least surprise via their ancestry chain, or whether they also moved to a "system" load view like Linux.
It's great that design decisions and thinking from decades past can be dug out and examined by complete strangers.
Of course, at this point, most people will be astonished when their Solaris (or Solaris-derived) or FreeBSD system shows CPU load instead of system load, given that most *ix exposure now happens via Linux.
As a "systems" guy I am always interested in how balanced the system is, which is to say that I am always trying to figure out what the slowest part of my system is and insuring that it is within some small epsilon of the other parts. If you do that, then system load is linear with workload almost regardless of task composition. So disk heavy processes load the "system" as much as "compute heavy" processes and "memory heavy" or "network heavy." In an imaginary world you could decompose a system into 'resource units' and then optimize it for a particular workload.
[1] http://dl.acm.org/citation.cfm?id=202217