Neil Bothwick <[email protected]> writes: > On Wed, 21 Dec 2016 22:48:29 +0100, lee wrote: > >> > You can't switch any two names because the udev rules are run singly, >> > so at one point you will be trying to rename an interface with a name >> > that is already in use. >> >> I mean more like renaming them on the fly --- or by having a >> configuration file with key:value pairs like 'enp69s0f1:eth3' --- or >> perhaps triples like 'enp69s0f1:eth3:"DMZ Interface"'. > > In that case you may as well leave the unique names in place and set up > recognisable aliases.
Sure, you can call the names you pick aliases. Can that be done? Not as in "going back to the old way", but as described. >> That way, you could have a recognisable name (or several names) for >> every unrecognisable one and assume that "eth3" or "foo" or however you >> want to call it is the same interface just as much as you would with >> unrecognisable names --- plus the advantage that when you ever need to >> change an interface, you only need to edit one small file rather than >> various configurations files having the unrecognisable name(s) in them. > > 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". 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, unless I changed a card for a different one after an udev rule had already been created. Now I can only assume that they will be called something. > 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. 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. 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. Being able to refer to things in more reliable ways improves the quality of the software. Using unrecognisable names for things reduces the quality. This is like you're defending a type of new pliers. The old ones didn't hold stuff as securely as the new ones do, but the new ones require that you use both hands to use them. The new pliers can provide an advantage for instances in which you do have to hold something very securely --- and in which another tool, like a vice, might be more appropriate anyway --- but for most of the time, they hinder you doing your work because they're so unwieldy. Of course, you call the new pliers "more secure pliers" rather than "unwieldy pliers", because that makes them easier to sell. Alas, "improvements" just like this seem to become more and more common, replacing actual improvements: The king gets new garments not seldom times, yet twice a day, and those who cry deceit are called not children but trolls. 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. > 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.
