From: Dan Cross <crossd@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] moving directories in svr2
Date: Mon, 3 Jan 2022 16:15:08 -0500 [thread overview]
Message-ID: <CAEoi9W7XPYwCJoQWscYFo6TM0XpPqSzcdiGCYLcdOyfdrXvmfw@mail.gmail.com> (raw)
In-Reply-To: <YdNbWqv9FMJMkgDZ@mit.edu>
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o <tytso@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.
next prev parent reply other threads:[~2022-01-03 21:16 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 3:45 Noel Chiappa
2021-12-30 4:02 ` Bakul Shah
2021-12-30 16:40 ` Theodore Ts'o
2021-12-30 22:31 ` Dan Cross
2021-12-31 0:43 ` Bakul Shah
2021-12-31 1:00 ` Rob Pike
2021-12-31 1:45 ` Bakul Shah
2021-12-31 2:23 ` Adam Thornton
2021-12-31 18:56 ` Chet Ramey
2021-12-31 3:08 ` Theodore Ts'o
2021-12-31 3:23 ` Rob Pike
2021-12-31 5:16 ` Theodore Ts'o
2021-12-31 5:21 ` Dan Cross
2021-12-31 5:55 ` Rob Pike
2021-12-31 13:32 ` Michael Kjörling
2021-12-31 15:53 ` Adam Thornton
2021-12-31 16:13 ` Arthur Krewat
2021-12-31 18:17 ` Dan Cross
2021-12-31 18:23 ` Larry McVoy
2021-12-31 18:37 ` Dan Cross
2021-12-31 18:29 ` Arthur Krewat
2022-01-01 0:09 ` Theodore Ts'o
2022-01-03 13:35 ` Dan Cross
2022-01-03 20:23 ` Theodore Ts'o
2022-01-03 20:45 ` Warner Losh
2022-01-03 21:15 ` Dan Cross [this message]
2022-01-03 22:26 ` Theodore Ts'o
2022-01-03 23:10 ` Dan Cross
2022-01-04 15:45 ` Chet Ramey
2022-01-09 19:28 ` Larry McVoy
2022-01-03 23:21 ` Doug McIntyre
2022-01-03 23:37 ` Adam Thornton
2022-01-04 14:49 ` Stuart Remphrey
2022-01-03 23:44 ` Larry McVoy
2022-01-03 23:56 ` [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) Greg 'groggy' Lehey
2022-01-07 19:01 ` Warner Losh
2022-01-09 17:31 ` Stuart Remphrey
2022-01-13 2:35 ` Kevin Bowling
2022-01-03 23:56 ` [TUHS] moving directories in svr2 Warner Losh
2022-01-04 2:28 ` Theodore Ts'o
2022-01-04 2:42 ` Larry McVoy
2022-01-04 9:28 ` [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) Rob Gingell
2022-01-04 15:17 ` Larry McVoy
2022-01-04 15:26 ` arnold
2022-01-04 15:40 ` Larry McVoy
2022-01-04 15:48 ` Richard Salz
2022-01-03 22:57 ` [TUHS] moving directories in svr2 Phil Budne
2022-01-04 15:40 ` [TUHS] VRFs (was Re: moving directories in svr2) Derek Fawcus
2021-12-31 5:12 ` [TUHS] moving directories in svr2 Bakul Shah
-- strict thread matches above, loose matches on Subject: below --
2021-12-29 19:33 Noel Chiappa
2021-12-30 3:40 ` Jay Logue via TUHS
2021-12-29 19:13 Douglas McIlroy
2021-12-29 19:37 ` Dan Cross
2021-12-29 20:15 ` Dan Cross
2021-12-29 20:42 ` Richard Salz
2021-12-29 20:58 ` Dan Cross
2021-12-29 21:20 ` Clem Cole
2021-12-30 3:15 ` Bakul Shah
2021-12-29 17:12 Douglas McIlroy
2021-12-29 16:59 Bakul Shah
2021-12-29 17:04 ` Clem Cole
2021-12-29 17:14 ` arnold
2021-12-29 17:38 ` Clem Cole
2021-12-29 17:49 ` Brantley Coile
2021-12-29 18:27 ` ron minnich
2021-12-29 20:59 ` Rob Pike
2021-12-29 14:33 Will Senn
2021-12-29 15:02 ` arnold
2021-12-29 15:38 ` Will Senn
2021-12-29 15:44 ` Richard Salz
2021-12-29 16:17 ` Clem Cole
2021-12-29 16:58 ` Richard Salz
2021-12-30 5:14 ` Dan Stromberg
2021-12-30 16:22 ` Clem Cole
2021-12-30 18:02 ` John Cowan
2021-12-30 23:04 ` Richard Salz
2021-12-29 15:17 ` Clem Cole
2021-12-29 15:44 ` Will Senn
2021-12-29 16:10 ` Clem Cole
2021-12-29 16:33 ` Warner Losh
2021-12-29 16:01 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEoi9W7XPYwCJoQWscYFo6TM0XpPqSzcdiGCYLcdOyfdrXvmfw@mail.gmail.com \
--to=crossd@gmail.com \
--cc=tuhs@tuhs.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).