[TUHS] moving directories in svr2

[Dan Cross]

On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o <tytso at mit.edu> wrote:
> On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote:
> > 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.  :-)

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.

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

Within a single organization, two semi-compatible ways of doing things
seems suboptimal for a number of reasons.

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