4 Jan
2022
4 Jan
'22
3:15 a.m.
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
Within a single organization, two semi-compatible ways of doing things
seems suboptimal for a number of reasons.
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.
On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross
wrote:
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.
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. :-) 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. > [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'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.