Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Alan McKinnon]

On 24/12/2016 03:52, lee wrote:
> Neil Bothwick <neil@××××××××××.uk> writes:
>
>> On Thu, 22 Dec 2016 04:15:50 +0100, lee wrote:
>>
>>>> There are no config files to edit with the predictable names, the
>>>> names are created from the physical location of the port.  That's why
>>>> they are called predictable,
>>>
>>> I only know what the names are when I can look them up when the computer
>>> is running.  I don't call that "predictable".
>>
>> If they are constructed according to specific rules, they are
>> predictable, by definition.
>
> You're overlooking that you need to know exactly, in advance, what the
> rules are applied to, and all the rules, for having a chance that your
> prediction turns out to be correct.  Provided you know all that, you can
> predict the universe, assuming that everything always goes according to
> rules.  You can not prove that it does and only disprove that it does
> when you find a case in which it doesn't.  So what's your definition and
> your predictions worth?

You keep mis-defining what "predictable" means in this context. It does
not mean, in the style of Newton, that you will always know everything
about it. Neither is it the same meaning as prediction in the context of
a scientific theory.

"prediction" here simply means that the interface name is guaranteed to
be the same as it was on last boot, and the somewhat random nature of
kernael names (ethX, wlanX) is not in play.

It does NOT mean that you are guaranteed to know exactly what an
interface will be called before you boot it for the first time.

Rename "predictable names" to "already known names" if it makes you feel
better. There's nothing wrong with this definition of predictable, as it
satisfies it's own rules and is consistent within itself. It is not
complete though but we already know that from Godel.

As long as you keep trying to apply the wrong meaning of predictable to
this situation, you will keep typing mails like this one I'm replying to
where you argue about something that is not even there. You also can't
realistically argue about what "predictable" means because like almost
all human concepts it is not a singularity, rather it is a spectrum
where it means what the author says it means.

And the quote for that meaning has already been posted in this thread
somewhere.





>
>>> They were much more predictable before because I could be reasonably
>>> sure that each of the ports would be called 'ethN', starting with N = 0,
>> "Reasonably sure" is not predictable.
>
> It's still better than something entirely unpredictable.
>
> Show me that the names are predictable by writing them down, then
> grabbing an arbitrary computer and plugging in a network card the
> port(s) of which will then have the names you wrote down.
>
>> A lot of this stuff is designed to
>> make automated management easier, so editing rules or config files is
>> undesirable. It is more about being able to automatically provision and
>> configure new systems, whether hardware or virtual.
>
> How does it help with that?  Wouldn't it help even more if you could
> just give them the names you wanted them to have?
>
> Like if you have N machines with an interface each you want to do
> something with, the only thing you'd have to do is make sure that this
> interface gets the right name assigned.
>
> With unrecognisable names, the interface can still have a different name
> on each machine.  What's the advantage of that?
>
>>> unless I changed a card for a different one after an udev rule had
>>> already been created.
>>
>> and being able to make changes without messing with the rest of your
>> system. I stand by my previous analogy of disk devices nodes vs UUIDs.
>
> Are they predictable?
>
>> One is readable the other is safe. Yes, you can use filesystem labels,
>> which can be both, but that requires intervention, just like your udev
>> rules. That doesn't make either approach wrong, just suited to different
>> purposes.
>
> And I would find it much better if network ports had recognisable names
> without intervention.
>
>>>> unless you move the NIC to a different PCI slot, it will always have
>>>> the same name, no matter what other hardware you add or remove. Yes,
>>>> the names are cumbersome, but they have to be like that to guarantee
>>>> their uniqueness.
>>>
>>> You don't need to defend the unrecognisable names.  The names used for
>>> referring to network ports don't need to be like that.
>>
>> No they don't. It is merely one solution to the problem, and the names
>> are recognisable, Alan posted the key earlier. They are complex and may
>> look cryptic until you understand them, but so is English.
>
> They don't become any more recognisable by knowing the rules.  They
> simply remain a combination of letters and numbers which is difficult to
> recognise.
>
>>> The perceived advantage lies in being able to refer to network ports in
>>> a more reliable way, and I don't see how using unrecognisable names
>>> instead of recognisable ones would make anything easier.
>>
>> See above re automation. It doesn't really matter whether you see the
>> need or not. If you don't have the need, don't use it, they are an
>> option for those who do want them.
>
> Unfortunately, that option has been made the default.
>
>>> It would have made things easier if the problem had been solved by
>>> giving them recognisable names (or aliases) by default --- or even if
>>> the default names (aliases) were the same as the unrecognisable names
>>> --- and allowing to easily configure the names (aliases) actually used
>>> to refer to the ports.
>>
>> That's a good point, and surely doable with udev rules, making the whole
>> argument moot. I haven't investigated because I don't have the need, but
>> I would be interested to hear what you discover.
>>  and not that unrecognisable once you understand the systax.
>
> I haven't investigated either because I figured there isn't much point
> in it because if I wanted recognisable names, I would have to put some
> extra work into every machine, which isn't a good option.  In the long
> run, it might be less time consuming to use recognisable names, but who
> knows if there isn't going to be yet another change, defeating a way I
> might have found to get such names back.
>
>>> Being able to refer to things in more reliable ways improves the quality
>>> of the software.  Using unrecognisable names for things reduces the
>>> quality.
>>
>> They are reliable, unlike your "reasonably sure" approach,
>
> I never said they aren't.  I don't see them as more reliable, either,
> not for any practical purposes.  Technically, they might be more
> reliable, but it doesn't matter to me.
>
>>> This is like you're defending a type of new pliers.
>>
>> I'm not so much defending them and expressing an opinion. I can see the
>> benefits and the drawbacks. They are an option, albeit one that is turned
>> on by default (but since when have Gentoo users ever been bothered about
>> upstream defaults?). Portage even gives you explicit instuctions on how
>> to permanently disable them with a single command, although I generally
>> use the net.ifnames=0 kernel option instead on single NIC machines, where
>> the feature is pointless.
>
> I didn't see portage or anything else give me any instructions or
> warnings about this.  The names just suddenly changed, and that screwed
> things up.
>
>>> But who knows, perhaps it is now possible to easily, on the fly, name
>>> the network ports through a neat configuration file.  I'm merely asking
>>> if there is because I don't know and would find that very useful.
>>
>> Can't ifrename do what you want?
>
> Dunno, I haven't heard of it before, it doesn't seem to be installed,
> and eix shows no hits for it.
>
>>>> How often you you have to type interface names anyway, and how many of
>>>> those are in a shell with tab completion that takes care of it for
>>>> you?
>>>
>>> None of them are, and I don't type the names.  They require copy and
>>> paste, or very careful and tedious typing after looking them up.
>>
>> Well, if you're scripting them, you only need to do it once per
>> interface, surely? That might be less work that setting up ifrename, but
>> use whatever works for you, your choices include, but are not restricted
>> to, and in no particular order.
>
> The issue comes up every now and then when I need to do something with
> network interfaces.  The unrecognisable names waste my time because they
> are unrecognisable, and that's really all they do for me.
>
>> Learn how the predictable names work
>> Disable the feature entirely and hope the eth0 names work as expected
>> Use udev rules
>> Use ifrename
>> Some combination of the above.
>


-- 
Alan McKinnon
alan.mckinnon@×××××.com