below... On Sat, Jun 16, 2018 at 9:37 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: ​Amen, although sadly many of us if not all of us have a few of these stories. In fact, I'm fighting another one of these battles right now.🤔 My experience is that more often than not, it's less a failure to see what a successful future might bring, and often one of well '*we don't need to do that now/costs too much/we don't have the time*.' That said, DEC was the epitome of the old line about perfection being the enemy of success. I like to say to my colleagues, pick the the things that are going to really matter. Make those perfect and bet the company on them. But think in terms of what matters. As you point out, address size issues are killers and you need to get those right at time t0. Without saying too much, many firms like my own, think in terms of computation (math libraries, cpu kernels), but frankly if I can not get the data to/from CPU's functional units, or the data is stored in the wrong place, or I have much of the main memory tied up in the OS managing different types of user memory; it doesn't matter [HPC customers in particular pay for getting a job done -- they really don't care how -- just get it done and done fast]. To me, it becomes a matter of 'value' -- our HW folks know a crappy computational system will doom the device, so that is what they put there effort into building. My argument has often been that the messaging systems, memory hierarchy and house keeping are what you have to get right at this point. No amount of SW will fix HW that is lacking the right support in those places (not that lots of computes are bad, but they are actually not the big issue in the HPC when yet get down to it these days). ​I think it was part of the same paper where he made the observation that the greatest mistake an architecture can have is too few address bits.​ My understanding is that the problem was that UNIBUS was perceived as an I/O bus and as I was pointing out, the folks creating it/running the team did not value it, so in the name of 'cost', more bits was not considered important. I used to know and work with the late Henk Schalke, who ran Unibus (HW) engineering at DEC for many years. Henk was notoriously frugal (we might even say 'cheap'), so I can imagine that he did not want to spend on anything that he thought was wasteful. Just like I retold the Amdahl/Brooks story of the 8-bit byte and Amdahl thinking Brooks was nuts; I don't know for sure, but I can see that without someone really arguing with Henk as to why 18 bits was not 'good enough.' I can imagine the conversation going something like: Someone like me saying: *"Henk, 18 bits is not going to cut it."* He might have replied something like: *"Bool sheet *[a dutchman's way of cursing in English], *we already gave you two more bit than you can address* (actually he'd then probably stop mid sentence and translate in his head from Dutch to English - which was always interesting when you argued with him). Note: I'm not blaming Henk, just stating that his thinking was very much that way, and I suspect he was not not alone. Only someone like Gordon and the time could have overruled it, and I don't think the problems were foreseen as Noel notes. ​I always wondered about the back story on that one. I do seem to remember that there had been a proposal for variable-length addresses at one point; but never knew why it was not picked. As you say, I was certainly way to junior to have been part of that discussion. We just had some of the document from you guys and we were told to try to implement it.​ My guess is this is an example of folks thinking, length addressing was wasteful. 32-bits seemed infinite in those days and no body expected the network to scale to the size it is today and will grow to in the future [I do remember before Noel and team came up with ARP, somebody quipped that Xerox Ethernet's 48-bits were too big and IP's 32-bit was too small. The original hack I did was since we used 3Com board and they all shared the upper 3 bytes of the MAC address to map the lower 24 to the IP address - we were not connecting to the global network so it worked. Later we used a look up table, until the ARP trick was created]. ​Amen and thank you.​ ​I know the feeling. To many battles that in hindsight you think - darn if they had only listened. FWIW: if you try to mess with Intel OPA2 fabric these days there is a back story. A few years ago I had a quite a battle with the HW folks, but I won that one. The SW cannot tell the difference between on-die or off-die, so the OS does not have the manage it. Huge difference in OS performance and space efficiency. But I suspect that there are some HW folks that spit on the floor when I come in the room. We'll see if I am proven to be right in the long run; but at 1M cores I don't want to think of the OS mess to manage two different types of memory for the message system.​ Indeed. But to be fair, you can also end up with being like DEC and often late to the market.​ M ​y example is of Alpha (and 64-bits vs 32-bit). No attempt to support 32-bit was really done because​ 64-bit was the future. Sr folks considered 32-bit mode was wasteful. The argument was that adding it was not only technically not a good idea, but it would suck up engineering resources to implement it in both HW and SW. Plus, we coming from the VAX so folks had to recompile all the code anyway (god forbid that the SW might not be 64-bit clean mind you). [VMS did a few hacks, but Tru64 stayed 'clean.'] Similarly (back to UNIX theme for this mailing list) Tru64 was a rewrite of OSF/1 - but hardly any OSF code was left in the DEC kernel by the time it shipped. Each subsystem was rewritten/replaced to 'make it perfect' [always with a good argument mind you, but never looking at the long term issues]. Those two choices cost 3 years in market acceptance. By the time, Alphas hit the street it did not matter. I think in both cases would have been allowed Alpha to be better accepted if DEC had shipped earlier with a few hacks, but them improved Tru64 as a better version was developed (*i.e.* replace the memory system, the I/O system, the TTY handler, the FS just to name a few that got rewritten from OSF/1 because folks thought they were 'weak'). The trick in my mind, is to identify the real technical features you can not fix later and get those right at the beginning. Then place the bet on those features, and develop as fast as you can and do the best with them as you you are able given your constraints. Then slowly over time improve the things that mattered less at the beginning as you have a review stream. If you wait for perfection, you get something like Alpha which was a great architecture (particularly compared to INTEL*64) - but in the end, did not matter. Clem ᐧ

On Sat, Jun 16, 2018 at 09:37:16AM -0400, Noel Chiappa wrote: To be fair, it's really easy to be wise to after the fact. Let's start with Unix; Unix is very bare-bones, when other OS architects wanted to add lots of features that were spurned for simplicity's sake. Or we could compare X.500 versus LDAP, and X.400 and SMTP. It's easy to mock decisions that weren't forward-thinking enough; but it's also really easy to mock failed protocols and designs that collapsed of their own weight because architects added too much "maybe it will be useful in the future". The architects that designed the original (never shipped) Microsoft Vista thought they had great "vision". Unfortunately they added way too much complexity and overhead to an operating system just in time to watch the failure of Moore's law to be able to support all of that overhead. Adding a database into the kernel and making it a fundamental part of the file system? OK, stupid? How about adding all sorts of complexity in VMS and network protocols to support record-oriented files? Sometimes having architects being successful to add their "vision" to a product can be worst thing that ever happened to a operating sytsem or, say, the entire OSI networking protocol suite. Definitely. The problem is it's hard to figure out in advance which is poor vision versus brilliant engineering to cut down the design so that it is "as simple as possible", but nevertheless, "as complex as necessary". - Ted