Re: [TUHS] moving directories in svr2

[Dan Cross <crossd@gmail.com>]

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

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.

> 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.

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.

> 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.