From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,LOTS_OF_MONEY, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12477 invoked from network); 3 Jan 2022 13:36:39 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2022 13:36:39 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9A8BA9499C; Mon, 3 Jan 2022 23:36:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 17B6893FD1; Mon, 3 Jan 2022 23:36:03 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="o9E4A6i8"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id EF23193FD1; Mon, 3 Jan 2022 23:36:01 +1000 (AEST) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by minnie.tuhs.org (Postfix) with ESMTPS id 6C8AB93FCC for ; Mon, 3 Jan 2022 23:36:01 +1000 (AEST) Received: by mail-ot1-f42.google.com with SMTP id w19-20020a056830061300b0058f1dd48932so43129426oti.11 for ; Mon, 03 Jan 2022 05:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nvRrrvafcJfbmgS9Bew7WUiaOUVWV2/Q5fkGj9OElJE=; b=o9E4A6i8VE7g68IJCEAUQaLWyT347dB2eQY0BczVFukBHOF8DWV588f5InSvbI1LUF CNxoaq67QT7xowAxwv/6Buz1lCsVZ3mRB8cq9ZchOaQW22p03JaXdfqsUgeGpu0MVHp3 qnP7jq8nR6HPe4iOuBQsWv0JjN2jilJqzHrGcI32iztZKwIuyFLHrbATt14T3MKF2+kU CnHVjel5kKRPKFb086+/w5gMRBuJr/qdRukE2wTadoFsDAJcq5cQhbRzuNTesPeCTIAs wLev/3qGeRVUC912OQy+0Fk1qQhqVqpZ7gqEp2fxM3JGBem8dkS22TGbu7OFFOrW4dxy dhCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nvRrrvafcJfbmgS9Bew7WUiaOUVWV2/Q5fkGj9OElJE=; b=x9hPVHtWp4g/k1ktd7Y9XPY/5nAons0Mva5K0XS3t9IsOPdE5WXZYB2m+1GQMu9Bae xjIJl+Ope8dsGW6dbGfVbxp5g/hPRoxwmtH9WqdkxpqOSZo6nGMt9d9Ye/MFUXywiB1z sgU2PchM1zay1zZF0kndXyv4J+zKF84mYwbZp7lxTmOwcFeci5Wx1EtdmWUySOdnV6Jd UFBOzPDjXINLF+2/hQUl6hcHYUGQnFmIFvqPRqYWgDGGtDY5czeB41iuM7n5kdvOntyp IynY8SPCNaQF+Vqd1z7bCYFcMgrsFifpqYqhrYV+y/ipnvFuAYq4a2kuYaK+/oN0KxeP Qwaw== X-Gm-Message-State: AOAM53319qNcHkX89leO1K3Jmcmw+5isj0WyKOOiFBLTZDrL0K+UAHXm k33T4bVVNus2/tHAfl3IVLOv3/3TjnRiUCjf2us= X-Google-Smtp-Source: ABdhPJxIyEkjaqFFDAUXvW04Ui63M/eMw83oTFBCVjoIJlHiwz1fv6v5qRy32MLaI5ooVgg2INOW05TWXE27WJo+AH8= X-Received: by 2002:a9d:7084:: with SMTP id l4mr32814522otj.225.1641216959960; Mon, 03 Jan 2022 05:35:59 -0800 (PST) MIME-Version: 1.0 References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> In-Reply-To: From: Dan Cross Date: Mon, 3 Jan 2022 08:35:24 -0500 Message-ID: To: "Theodore Ts'o" Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] moving directories in svr2 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Fri, Dec 31, 2021 at 7:09 PM Theodore Ts'o wrote: > On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote: > > On Fri, Dec 31, 2021, 10:54 AM Adam Thornton wrote: > > > Slightly older, but also slightly more fundamental to the system, you need > > > look no farther than Solaris's `/bin/sh` for an illustrated example of the > > > pros and cons of maintaining backwards compatibility. [snip] > > > > Sun is not the exemplar here: the move from SunOS 4's BSD userland to > > Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their > > customers had to pay the cost of adaptation. > > I'm sure that there were people at Sun who *did* care. Oh I think we know from first-hand accounts that there were _people_ there who cared. When I wrote "they" earlier I was referring to the corporation (since those are people now, you know!) which clearly didn't; or at least made a decision that indicated that they thought the cost was worth it. > The story I > had heard was that it was a decision made at the C-suite level, and > was a quid-pro-quo where to get that sweet, sweet, cash from AT&T so > Sun could stay afloat, they had to switch over to System V. I wouldn't kick AT&T's $100 million out of the house for running System V. > (No > matter that Solaris 2 was a major step *backwards* in terms of > performance and stability compared to Sun OS....) That it was, at least initially. It's actually pretty good now, but it took a _long_ time to get there, and the forced incompatibilities caused a lot of pain in the process, which was my original thesis. Even now, though, I find some things gratuitously different than other versions of Unix (network administration, for example). Managing NFS is still something of a mystery to me. > > The Linux example is also a bit strange. The move from e.g. `ifconfig` and > > `netstat to `ip` and `ss` required lots of local retooling (I suppose some > > distros retain the older tools or let you install them as an option. I > > suppose one could always install `bash` on Solaris as a shell lingua > > franca, as well). Not to mention systemd. The point is, breaking changes > > are introduced all the time. > > Are there distros who are no longer supplying ifconfig/netstat/route, > at least as an optional package? That's surprising if so. Are there _distros_ that don't supply those things? Probably; I really have no idea. Are there mainstream distros that do not? I doubt it. However, they have to be installed, which is an additional step that has to at least be accounted for. At scale, that's a pain: I imagine that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et al in prod, it would be a multiyear process, including sunsetting the older tools. Just identifying every use of `ifconfig` in a shell script somewhere would be a pretty major undertaking. > All of the kernel interfaces to allow the old-style net-tools packages > to work, as well as the BSD-style ioctls/setsockopt, etc., are still > around, and fully supported. At least on my systems, I still install > net-tools because my finger macros are still used to using ifconfig, > netstat, and friends. By virtue of the existence of that additional step, however, there is an incompatibility with the "older" way of doing things. By no longer being the default, it is (in perhaps a minor way) a breaking change. > The reason why ip and ss were added was because there was a > significant amount of new functionality that was added to the Linux > networking stack (especially relating to routing and address aliasing) > that couldn't be expressed using the older C programming interfaces as > well as the ifconfig/route shell commands. Surely the programmatic interfaces are separate from their realization in a tool? I can understand the rigidity of some `ioctl` based interface that's a pain to work around; I find it harder to believe that plugging some other interface into `ifconfig` in a relatively graceful way is untractible. Surely, in the limit, one could extend ifconfig with a new verb as the first positional argument that expands to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that was considered and rejected by the maintainers. > There were two north star > principles about the new networking interfaces: > > 1) The old interfaces were always supposed to continue to work, and if > you didn't need the new functionality, there was no reason to use the > newer interfaces. > > 2) The new interfaces were *supposed* to be a strict superset of the > old interfaces. > > If in fact ip and ss don't support AX.25, or other "exotic address > families" --- that's a bug, and should be reported as such. This is an aside, but I'd suggest taking the opposite approach: rip AX.25 out. It has serious bugs (including, apparently, leaking kernel memory into transmitted packets?!) that have gone unfixed for years. My AX.25 machine panics on reboot if there are active netrom connections, and netrom packet state isn't cleaned up properly. The maintainers seem to be out to lunch and are unresponsive on linux-hams. Personally, I'd prefer to see a FUSE-like mechanism for implementing things like AX.25 in user-space: that would make it much easier to fix things like that. On plan9, I would implement AX.25 as a userspace program that exported a small filesystem and bind-mount it onto /net. On Unix, a similar thing could be done with Unix-domain sockets and daemons muxing the radio, but it wouldn't integrate nicely with the existing tools. That's a problem with doing everything in a tightly coupled, monolithic way. > That > being said, if you don't need the fancy new features, there's no > reason to switch away from ifconfig. The whole *point* of the first > principle was that we didn't want to force users to do a forced Python > 2.7 -> Python 3 style "long march" migration. Well, you kind of have. It's a small thing to install another package, sure, but still something that must be done if you want the old tools. - Dan C.