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=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11154 invoked from network); 3 Jan 2022 22:27:11 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2022 22:27:11 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E5E9494A73; Tue, 4 Jan 2022 08:27:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 88B2E93FD1; Tue, 4 Jan 2022 08:26:41 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3A89093FD1; Tue, 4 Jan 2022 08:26:39 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 9E07193FCC for ; Tue, 4 Jan 2022 08:26:38 +1000 (AEST) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 203MQYvW017553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Jan 2022 17:26:34 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id D897D15C00E1; Mon, 3 Jan 2022 17:26:33 -0500 (EST) Date: Mon, 3 Jan 2022 17:26:33 -0500 From: "Theodore Ts'o" To: Dan Cross Message-ID: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > 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. I've seen a number of large-scale data center environments that use DHCP; and those that don't in Linux-land generally just edit a config file in /etc/network/interfaces or /etc/network/interfaces.d --- and then the init scripts would just use "ifup -a" which would bring up the network either using DHCP or the hard-coded values in /etc/network/interaces. No need to have sysadmins manually typing "route add ..." commands except in extreme debugging situations. > > 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 actually suspect the number of users who want to run MySQL is actually larger than the number of users who need to manually configure a network using /sbin/ifconfig and /sbin/route.... :-) > 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. Google prod's easy --- Google maintains its own minimal prod distribution where a small set of packages (less than a few dozen) that were originally forked from Debian a number of years ago. So it's trivial for us, because net-tools is installed by default and there is **no** engineering upside for us to switch to ip/ss --- so we haven't. :-) Similarly, we're still using a *very* old version of bash (having stayed back across multiple major releases) because it's easier to stick with an old version of bash and keep up with the security fixes, than it would be to audit a gazillion shell scripts and shell script fragments for the various potential and subtle backwards-incomaptible changes that bash has made over the past decade. Larry has told a similar story about the advantages of using a "dead" language like Tcl for Bitkeeper, since he didn't have to deal with gratuitous version skew problems caused by backwards incomaptible changes in Perl or Python. But if you manage your own userspace, including affording to do your own FEDRAMP-compliant security updates, you can just choose *not* to upgrade to newer versions of bash or network utilities. Who *says* you have to use bash 5.1? Or switch to ip/ss? On the other hand, we did spend untold engineering hours migrating from Python 2.7 to 3.x (and *wow* was that painful) because in that case, that was considered less work and more secure than independently supporting Python 2.7 ad infinitum (also, we have fewer Python programs than we have shell script fragments in config files like Makefiles as well actual shell scripts). So the decision about whether to follow breaking interfaces/language changes is an engineering decision that's made on a case by case basis, as it should be for all organizations. In the case of bash and net-tools, one decision was made. In the case of Python, a difference decision was made --- although a lot of people really weren't happy that the Python developers didn't appreciate the cost of breaking backwards compatibility (or rather, they decided that they didn't care and prioritized their own convenience over that of their users). This is why I'm a big supporter of Linus's, "Thou Shalt Not Break Userspace" rule; backwards compatibility at the lowest levels is important! I'd draw that line higher than some people, but hey, if you don't like the instability of Python, you can do what Bitkeeper did and base your extension language/scripts on something like Tcl instead. - Ted P.S. If you want to see the horror of trying to support a Python program that has to be able to run on a wide variety of Linux distros, running different versions of Python (from RHEL 6 and Python 2.3 up to the newest bleeding edge Python 3.x), take a look at the Google's gcloud program. Alas, unlike the Google prod environment, we can't dictate what distro our Cloud customers might choose to use. The gcloud command (part of the Google Cloud SDK) has to play all sorts of portability games, and people need to continually test across a wide range of Python versions and Linux distros to provide assurance that it continues to correctly as new features are added and bugs are fixed. I *completely* understand why Larry chose to implement Bitkeeper extensions in Tcl, since it avoids this problem. Bt yeah, it's why I wouldn't want to change dot-dot, since having seen the pain the Python developers inflected on me, I wouldn't want to inflict it on others...