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

[lee]

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?

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