On 2019-06-25 at 09:28, Michael Stone wrote: > On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote: > >> On 2019-06-25 at 08:11, Michael Stone wrote:
>>> It isn't because: 1) the new names are predictable but not
>>> constant, so you can't configure a single default across all
>>> systems
>>
>> Which seems reasonable to describe as "unpredictable".
>
> They're perfectly predictable for a given system.
And reasonably unpredictable between systems.
Just reiterating the case where they *are* predictable misses my point
so badly that it almost seems as if it must be intentional.
> The old names also weren't constant, but people didn't seem to care
> as much about the nuances because "that's the way it's always been".
> (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were
> those differences ok but these differences aren't? Familiarity.
No, not just familiarity.
To the best of my awareness, the old names were 100% constant, as long
as you had no more than one interface *of a given type*.
And because you have to deal differently with interfaces of different
types (wireless interfaces need different userspace software from what
you need for wired ones), naming them differently - but still
predictably, in the same sense as before wireless interfaces ever
existed - was useful, because it let you easily distinguish which ones
needed which type of handling.
With the new names, the fact that two interfaces get different name
prefixes (etc.) tells you basically nothing useful about how to handle
them; it just exposes underlying hardware details of some kind, which
you don't actually need to know in order to make effective use of those
interfaces.
>> On a single computer with any number of interfaces of any type, the
>> new names are 100% predictable from one boot to the next. (At least
>> assuming you don't change which slot a given network device is
>> connected to; IIRC that can change the assigned name, in at least
>> some cases.)
>
> That does change the name, that's the entire point.
With no real benefit as far as I can tell, but yes.
It's also rare even on servers, much less on end-user systems (which
tend to have the network device hardwired into the motherboard, as often
as not). I only included that line for completism's sake - and
apparently it even misses a few cases where things can change even
without doing that, at least one of which I hadn't even considered.
>> Computers with multiple interfaces of the same type are, AFAIK
>> always have been, and IMO are likely to always be, much less common
>> than computers with at most one interface of a given type.
>
> They're also the only computers where the name actually matters. In
> the simple case it's set at install time and doesn't change, so it
> could be completely random and it wouldn't make a difference.
It matters if you're giving someone directions, with the computer sight
unseen.
Before, you could write directions - or even a script - which just
referenced 'eth0' and/or 'wlan0', and hand the result out Internet-wide,
with assurance that it would work reliably for the large majority of people.
Now, you have to do something to detect the interface(s) and choose the
right one.
>>> They are tremendously helpful if you build servers with multiple
>>> interfaces, or you ever have to swap out a broken nic. If you
>>> have a simple system it gets set once at install time, so who
>>> cares?
>>
>> Among possibly other things: anyone who has to work with multiple
>> systems with different hardware configurations, which have at most
>> one interface of each type.
>>
>> Imagine carrying around a live-CD type of environment, for
>> rescue-boot or maintenance-boot purposes, to use on end-user
>> computers. I work in exactly that situation, and adapting - both
>> scripts, and tech habits / expectations / etc. - to the way network
>> interface names now vary between machines has been quite a pain.
>
> ifquery --list | grep -v lo
And what about when you only want the wired interface, or only the
wireless one, but the machine might have one of each type?
(Plus, I'm pretty sure the environment I work with doesn't have ifquery;
it has ifconfig, but not necessarily much beyond that. The older
versions didn't even have a DHCP client more sophisticated than dhcpcd.
I can add tools to it, but that becomes a pain to maintain, for the same
reasons as adding 'net.ifnames=0' to the kernel command line would be.)
> If there's more than one result, it was going to be hard "the old
> way" also. More portably, something like
Why?
Just using 'eth0' blindly wasn't hard at all, and since we're dealing
with single-user workstations which will never have more than one wired
and one wireless interface, it was a safe assumption to rely on.
> ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") print $2}'
>
> or
>
> ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") {print $2; exit 0}}'
>
> if you just want the first interface
I want the first (only) *wired* interface. Do the new names even
distinguish between the types? (I haven't paid them enough close
attention to have the necessary awareness of what names result in order
to be able to answer that question with any confidence.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
