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,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2105 invoked from network); 3 Jan 2022 21:16:16 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2022 21:16:16 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2F46094A7A; Tue, 4 Jan 2022 07:16:13 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C5FB693FD1; Tue, 4 Jan 2022 07:15:50 +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="ENtCYGfQ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 76D2493FD1; Tue, 4 Jan 2022 07:15:47 +1000 (AEST) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by minnie.tuhs.org (Postfix) with ESMTPS id 034AF93FCC for ; Tue, 4 Jan 2022 07:15:46 +1000 (AEST) Received: by mail-ot1-f43.google.com with SMTP id n17-20020a9d64d1000000b00579cf677301so4138336otl.8 for ; Mon, 03 Jan 2022 13:15:45 -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=4p9PIVF2RCIoSdJfkyyWRAJZ+H/V30QxEPGCbrVuK6Q=; b=ENtCYGfQrsrbx3Ma57ezVFgZH+KdmiifKN8ICjk8QT9K2kcMv0M80u69xuu0YJs5lI mSmHzDVwT1zyHhQKvbm+c2uhTKV50Ka2De4BihylUOa//6CrcXJ4ImyxX3+SEWx7E9Db dlC24G/bagEuBiDlQCW5UJhEY4w8Sn5iyF3DA3hEUGs0zDdWxseSOWVqC30ozeio7BNH fYGY0aKOerKvesM9We4WkZRcBFK7VjcI1nFQRNzPL/HqPO57aqt3al4fCEkpekq/HXCd AXqHXVwH6gJG1aaGcVf8wWs14rz/tsgGK+DgmIizkmNd0zHrXJGJEdjSujyibcAGp2t5 nK+Q== 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=4p9PIVF2RCIoSdJfkyyWRAJZ+H/V30QxEPGCbrVuK6Q=; b=183+FGKKO5wNeuWKfcJXfsVmDtbH2KA2jAv6mlMrVrqDu6cUh+pcqWnLdtwCz0bPBw 3158AMllGzq2A+qA0mwlkls/cFFSQm77/YCJvXm7bkr2SU3QZqzQGGOCjmZqea2PoJjq LWRft48GQ/B4RPAYLXnLGcuXqGz4EO8tGkh9PchF2FxWLo95HdNdgVSj4bCyuPrDzad9 8+Dt5HuDxLoZPVz0Jq5Z/52pkR9Lh81JV70h6D/wmiUPCsx1ho5rac/3MlbhHannzSoA Ju/1tPftWia0RGXgjo9UMPM4jqX2IrsCv1U6zoLqUT/ze7QxLe53o8gZkMk8S/dmtUEw lqng== X-Gm-Message-State: AOAM533QaheQDO7bEB9IoQvjGjvACTu7t+EQrPGYx3dABR/mJezxJ7zD SfeWN+kxxgcVp8GraZcsG7h1YeNEuXO0cEP0dOU= X-Google-Smtp-Source: ABdhPJx7zamS5UMlwzEUEu7I4oyn1CG4RMd62kUj4FaiZe2cH0osQl5QMRgTDvLFuKi58p7H9bH6ly2rOvQpqrjx7QQ= X-Received: by 2002:a9d:4d10:: with SMTP id n16mr34436306otf.17.1641244545077; Mon, 03 Jan 2022 13:15:45 -0800 (PST) MIME-Version: 1.0 References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> In-Reply-To: From: Dan Cross Date: Mon, 3 Jan 2022 16:15:08 -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 Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote: > > 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. > > [snip] > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > mostly up to par. (Or maybe it was because Moore's law meant that we > didn't care any more. :-) I have some vague memories that we had to do something like double the RAM in our SPARCstations to make Solaris 2 feel comfortable. At the time, that was a pretty serious outlay in an academic department. 2.5.1 felt like the first version that was _truly_ usable. > > 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. > > Sure, but there's no *point* to sunset the old tools. The git tree > for net-tools is still being actively developed (the last commit was > dated December 12, 2021). And the kernel interfaces are not going to > be disappear, because of the prime directive: Thou Shalt Not Break > Userspace. Within a single organization, two semi-compatible ways of doing things seems suboptimal for a number of reasons. > > [snip] > > 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. Jon Steinhart reminds me that he said largely the same thing last week; credit where it's due! > Well, take a look at the ip-route man page. The BSD route command > assumes fundamentally there is a single routing table that you can > update. In Linux, there are multiple routing tables --- to support > NAT, VRF (virtual routing and forwarding), etc. As Warner mentioned, the BSDs also support multiple routing tables, with the `route` command. To bring it back to ham radio, I not-so-humbly offer up https://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenBSD as a rather pedestrian example of their utility. > I suspect the other consideration was that all of this extra > functionality and complexity were done by folks who wanted the Linux > networking stack to essentially have pretty much all of the > functionality of a Cisco Router. So it made sense to create a new > user interface interface that was inspired by the Cisco IOS > configuration language. I would suggest that the latter does not necessarily follow from the former. But if people want to evolve things, that's ok: after all, the genesis of this discussion is that we know how to handle breaking changes. > Now, if you weren't trying to do something > ala a router in the default-free zone, and were just simply doing what > most leaf nodes on the internet (99.99999% of the hosts), there really > is no reason to need to use the ip/ss interface. Except that's what a lot of documentation tells you to do. :-) Really, `ip` and `ss` are basically fine. The overriding point is that when one says on the one hand, "we cannot change the way `..` works because people's scripts might break..." but we fundamentally change the default network commands on the other, the former seems to be self-invalidating. > For that matter, you > probably don't need to use ifconfig/route --- just let the DHCP client > server of your choice take care of setting up the network, and you're > done. That'll work on a laptop or on my home network (where I set up the DHCP server). In a large-scale datacenter environment, maybe not so much. > > 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. > > That's a distro-level choice. And for most users, their networking is > automatically brought up using NetworkManager, or some such, so they > probably don't care. And it's not like installing a package is that > painful. I don't see users of say, mysql complaining that they have > to install that package should they want to use it. I would suggest that the number of users who want to run MySQL is much smaller than the number who want to have a functioning network. But you're right; it's not that hard to adapt. That was kind of the point; there have been cases where Linux users have adapted to one degree or another. > I'm old school, and since I generally tend to install BIND, that will > drag in net-tools as dependency, so all my systems have ifconfig > installed. But I'm not going to have a lot of sympathy for someone > who thinks that "sudo apt-get install net-tools" is massive > inconvenience. Since shells often have custom (and occasionally inconsistent) handling of `..`, I'm not sure I'd have a lot of sympathy for that one either. Why one and not the other? I suspect Clem got it right: it has to do with the perceived value of the change. The networking stuff had sufficient value that it was worth the cost incurred (which is low, but non-zero). Perhaps changing `..` just wouldn't have the benefit. I argue that it's hard to know those things beforehand. The `apt install net-tools` thing is a red-herring, though: that's explicitly why I mentioned Google prod. What works on a single system doesn't necessarily scale to O(10^6) machines supporting O(10^7) separately running instances of O(10^4) services in O(10) globally distributed datacenters, that's just a single organization. - Dan C.