On Sat, 26 Aug 2017 at 13:11:36 -0400
Hendrik Boom <hendrik@???> wrote:

> On Sat, Aug 26, 2017 at 07:02:41PM +0200, Alessandro Selli wrote:
>> On Sat, 26 Aug 2017 at 17:19:48 +0200
>> Didier Kryn <kryn@???> wrote:
>>

>>>      AFAIR I fully agreed on that and then it jumped into my face that 
>>> the renaming wasn't necessary at all, because it is sufficient to know 
>>> the MAC address and ignore completely the interface name. It is just 
>>> enough for this to work that the tools manipulating the network 
>>> interfaces can be given the MAC address instead of the interface name. 
>>> This opens an alternative to renaming: guaranteed stable interface 
>>> reference, no race condition and no need for a new name space.  

>>
>> This is not a good solution when you want networking to work just the
>> same even when you replace or shuffle your networking hardware around,
>> expecially with USB devices.
>
> It seems we are approaching the paradox of the well-darned sock.
> At what point are we to consider an interface to have changed?

Right, both the admin and the system will easily agree on the fact that an
interface is new. But what about it's name to be assigned? Is it new
because it's replacing a previouly used interface, or is it new because it's
going to be used for something unrelated to the other interfaces that the
system has seen before? how is the OS supposed to know? It cannot, so any
NIC renaming gimmick will have to provide for a way the sysadmin to impose
their own naming scheme. My vote will go to the system that:

1) uses the shortest and easiest to identify and remember names (en0 and wf1
are good choises, enp0s23 so so, etf45a09dc634 is awful)
2) is as easy as apple pie to reconfigure to fit any specific environment
(which is a thing udev got wrong).


Alessandro