From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A59771F5AE for ; Sat, 1 Aug 2020 00:17:55 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4C2733857C75; Sat, 1 Aug 2020 00:17:54 +0000 (GMT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) by sourceware.org (Postfix) with ESMTPS id 259633858D35 for ; Sat, 1 Aug 2020 00:17:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 259633858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=columbia.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fd1@columbia.edu Received: from pps.filterd (m0167071.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0710ERPt032382 for ; Fri, 31 Jul 2020 20:17:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=LbzqVsw0VZWKmJnHlt6Pdx5oLR2a93v6q4yfOnSYrYw=; b=K9BDk3sn/87AD2Kki2azzuPOpJ74xMvhjMrOKoGtl5KAuqIhxhK7BxwwKfsWjpdqpe+N /6g7Ts+sdhyTsRrDQrXeu+F0oyHkZ5ahI+QbCe+pW6wkXGbaQcEXPaGSZz/wQIcsDd3H 3jcSxLGooLu6ptu/0As/plX7Z1/BeJu2eY1Fx0Bhmf82tne9i5QjWyXjorNC9ZAAWNff HPNzQL6BmTPZXHwsvM2F91A2dy7qLR8d0ePUQWenUjMnj875aT0RZcpkMyDwSPtzq6QG BrhTv5Ws3zAhPl4b63SMq58gZHQhn+ulznPSJtZ45D0+AtR7GuV/yIxbzZGp/EndJful bA== Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 32jkqtewcs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jul 2020 20:17:47 -0400 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0710HjVf040433 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 31 Jul 2020 20:17:46 -0400 Received: by mail-il1-f197.google.com with SMTP id l6so11733143ilf.8 for ; Fri, 31 Jul 2020 17:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LbzqVsw0VZWKmJnHlt6Pdx5oLR2a93v6q4yfOnSYrYw=; b=V6ybGAjKH1HPlGmje43ag6OXyNRy9Ztbpi5MeOcox+QtG8lrobUeMvvHIeWnZAh4o/ kKScbC3jDC+P0rlicI0SQU5VJKyd05FbbCXEoyzwVKSvjxtGSUxz/vOQYN7NJ1PG6Eu5 i8A9eu424NXoGQwA9ftbNF8VBl0x27vTYUPvnjWZn2vSGnJnMK/6WuqyWnNi9tCyt4K4 io9az5RUdH3Xvp3LbIW+k6LJo7+O+OZRIRxabOYqNBJfV0/1QoOQ3N/NlTVyIEnal6Oq iYp1Xjbr2DRPZks2211lxKrfjWAct7MFv3NbvIG2km5WStKWIMellzUjf1twIeUVp/TG /Jsw== X-Gm-Message-State: AOAM531e2L5QvO3xUT4X5w6wveFhrg6jao6jNdWX2AIVRqhuajkyr1ba 6xrugfWb+4RPm5MdpSqxV8Lo11MaFzA1Yski5H1J4CXE4I9rWsIbGUIEAnlfgiNJo/1AEU5rFTc qGDdgvJboXXqEqw4MYZjEz50eLLNqz4wu4e9LYTha9/9F X-Received: by 2002:a05:6638:1649:: with SMTP id a9mr8111901jat.115.1596241065381; Fri, 31 Jul 2020 17:17:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkJ4V45+u3V72K2FeCjERveVz/5Izs5z3qtm/0MwOk0BmwmGOM37fa1N81YzvPaVai0jORkZ8JChOt4g+LJtY= X-Received: by 2002:a05:6638:1649:: with SMTP id a9mr8111879jat.115.1596241065053; Fri, 31 Jul 2020 17:17:45 -0700 (PDT) MIME-Version: 1.0 References: <10CAD3CD-0170-4182-A920-EE825EBAF6B0@rmrco.com> <95d9170b-d925-5037-c841-e1fd17bb680f@cs.ucla.edu> In-Reply-To: From: Frank da Cruz Date: Fri, 31 Jul 2020 20:17:33 -0400 Message-ID: Subject: Re: C-kermit fails To: Paul Eggert X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-31_09:2020-07-31, 2020-07-31 signatures=0 X-Proofpoint-Spam-Reason: safe Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Liam Stitt , Frank da Cruz , Mike , GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" You're right, there was also some awful stuff in the good old days but somehow it didn't affect me much. We ran an IBM 360/91 for 11 years and never experienced any software rot. The DEC-20s were especially good; we field-tested each new release of the OS (TOPS-20) and any problems that we reported, they fixed. During normal operation, between field tests, if we ever found a problem we submitted an SPR (software performance report) and they fixed the problem promptly; applications continued to work through five or six major OS releases. The important point was the vendor's commitment to not breaking existing applications, including well-defined mechanisms for reporting problems when they occurred and getting them fixed, rather than a response to the effect of "we have deprecated that feature". Of course eventually these proprietary platforms and OS's ceased to exist and then it was back to Square One for everybody. That's why I appreciate Unix so much, and why I am so sensitive when Unix (Linux) OS packagers deliberately remove features that people use. In the present case, I would ask what harm is there in leaving the stdin buffering items where they have been all these years? If they were a bug or a security risk, there might be a reason to remove them but only if the bug or risk could not be fixed without doing so. If I was in charge and I believed there was something unhealthy about the current mechanism, I would add a new function to do the same thing (stdin buffer-peeking), explain its advantages, and recommend that applications "migrate" to it over time, but I would still leave the old stuff in place because, unless I'm missing something, there is no good reason not to. The first rule should be, "do no harm" because you never know what the effects be be down the road. - Frank On Fri, Jul 31, 2020 at 4:23 PM Paul Eggert wrote: > On 7/31/20 11:22 AM, Frank da Cruz wrote: > > Software development was not like > > this when computing was dominated by companies like IBM and DEC, who were > > dedicated to preserving their customers' investments in software because > if > > they didn't, they'd lose those customers. > > That wasn't my experience at all. IBM and DEC regularly broke user > applications > and said the equivalent of "If you don't like it, then just keep running > the old > OS on the old hardware." They then tried to sell you new stuff, and if you > refused they eventually stopped supporting the old stuff. > > For example, circa 1978 if you wanted to use a PDP-11/70 and selected > DEC's > operating system RSTS, you would have been kinda out of luck by around > 1983 when > the PDP-11/70 was obsolete. DEC told customers to switch to VAX/VMS, and > gave > some upgrade paths (late-1970s VAX hardware would emulate PDP-11s and if > you > threw DEC some more money VMS would support RSTS user processes, albeit > inefficiently) but DEC dropped those upgrade paths in later VAX hardware > and you > were stuck. The last RSTS release was in 1992 and DEC stopped supporting > RSTS > soon after. > > Had you selected Unix instead in 1978, you'd have been golden. Your > software > would still run today, with only minor changes. I still run some personal > Unix-based software now that I originally ran on a PDP-11 in the late > 1970s. > > And it wasn't just DEC. I remember the FAA using IBM mainframes in their > air > traffic control systems designed in the 1960s and written in 360 assembler > with > CCW programs. The FAA kept running this stuff on an old IBM OS on old IBM > hardware until IBM told them around 1980 that IBM wouldn't support it any > more. > IBM then sold the FAA on a replacement system called AAS that cost > billions and > never worked. See > < > https://www.sebokwiki.org/wiki/Federal_Aviation_Administration_(FAA)_Advanced_Automation_System_(AAS)> > > for some of this sad history. > > Although I'm sure one can cite examples of old-time backward > compatibility, I'm > exceedingly skeptical that the old days were any better than now overall > in that > department. Quite the contrary. In particular, the GNU C library is *much* > better about backward compatibility than IBM and DEC were in the "good old > days". >