3 Jan
2022
3 Jan
'22
7:35 p.m.
On Fri, Dec 31, 2021 at 7:09 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
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.
On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross
wrote:
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.
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton
<athornton(a)gmail.com> wrote:
I'm sure that there were people at Sun who *did* care. 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. 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. 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.