4 Jan
2022
4 Jan
'22
4:26 a.m.
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
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.
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.... :-)
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. 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. 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...