From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 0ed7dff6 for ; Sun, 17 Jun 2018 17:58:32 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 49665A19E9; Mon, 18 Jun 2018 03:58:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E58DEA19D4; Mon, 18 Jun 2018 03:58:17 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 114C3A19D4; Mon, 18 Jun 2018 03:58:16 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id B6E5FA19D3 for ; Mon, 18 Jun 2018 03:58:15 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D8BAD18C0A7; Sun, 17 Jun 2018 13:58:14 -0400 (EDT) To: tuhs@tuhs.org Message-Id: <20180617175814.D8BAD18C0A7@mercury.lcs.mit.edu> Date: Sun, 17 Jun 2018 13:58:14 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] core X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > From: "Theodore Y. Ts'o" > To be fair, it's really easy to be wise to after the fact. Right, which is why I added the caveat "seen to be such _at the time_ by some people - who were not listened to". > failed protocols and designs that collapsed of their own weight because > architects added too much "maybe it will be useful in the future" And there are also designs which failed because their designers were too un-ambitious! Converting to a new system has a cost, and if the _benefits_ (which more or less has to mean new capabilities) of the new thing don't outweigh the costs of conversion, it too will be a failure. > Sometimes having architects being successful to add their "vision" to a > product can be worst thing that ever happened A successful architect has to pay _very_ close attention to both the 'here and now' (it has to be viable for contemporary use, on contemporary hardware, with contemporary resources), and also the future (it has to have 'room to grow'). It's a fine edge to balance on - but for an architecture to be a great success, it _has_ to be done. > 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". Absolutely. But it can be done. Let's look (as an example) at that IPv3->IPv4 addressing decision. One of two things was going to be true of the 'Internet' (that name didn't exist then, but it's a convenient tag): i) It was going to be a failure (in which case, it probably didn't matter what was done, or ii) it was going to be a success, in which case that 32-bit field was clearly going to be a crippling problem. With that in hand, there was no excuse for that decision. I understand why they ripped out variable-length addresses (I was just about to start writing router code, and I know how hard it would have been), but in light of the analysis immediately above, there was no excuse for looking _only_ at the here and now, and not _also_ looking to the future. Noel