<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <link href="chrome://translator/skin/floatingPanel.css" type="text/css" rel="stylesheet"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Xen, Thanks for going to bat for us on this--sorry that no one wanted to hear you. Odd that a Debian dev would balk at this... Last I loaded the latest Debian (about a month ago), I got the good-old "ethx" interface names. Hmm.... Totally agree with your assessment that the argument "for" this new naming scheme is ludicrous and illogical... Thankfully, there is a relatively simple way to disable this scheme ( <a class="moz-txt-link-freetext" href="http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04">http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04</a>). Thx. -ml <div class="moz-cite-prefix">On 7/20/2016 1:56 PM, Xen wrote: </div> <blockquote cite="mid:cd352a787826de471b7835c547ceabe0@dds.nl" type="cite">Markus Lankeit schreef op 20-07-2016 0:01: <blockquote type="cite">Also, the whole network device naming scheme is just a fiasco... Before, I could have a simple template for all my systems... now every system requires a unique template that takes me to the HW level to figure out what it might be. And this is supposed to be more intuitive and/or predictable than "eth0"? </blockquote> I've tried to make a point of this recently on the systemd-devel list but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none of it and a kernel developer tried to show me off into the woods by coming up with thought experiments as to why any other solution would not be viable. Basically I just think they have an agenda and won't admit to it. Many illogical decisions become logical the moment you know the truth. There are probably some business customers that need flawless device recognition while requiring absolute zero configuration from the viewpoint of the boot process. Any other strategy would work, including condensing the detected hardware list for onboard/unpluggable devices only. They tried to tell me that a Linux system was capable of recognising a hardware device that was present during boot only hours after the system was booted - theoretically - and that because of this a stable "condensation" into names such as ethernet0 would not be possible. Ie. what if after 3 hours of using the system, a network card will suddenly pop up? What then of your numbering? Now you have to insert another card in the number and your numbers won't be right anymore. That is the ludicrous argument to my counterargument that they gave me. Ie. I believe the network card detection works by trying all drivers and seeing if they can find any card they can manage, this is a pretty deterministic process and will probably end pretty fast for any driver seeing how fast the system boots these days (particularly with SSD) and never has a problem. If any driver cannot find any hardware, it is removed from the list and never tried again. So apparently (according to kernel documents I read online) this is a pretty bounded thing with a guaranteed endpoint depending on whether any drivers do anything really weird, which I think they don't. However lacking my real knowledge of the thing they were able to pretty much shove me off into the woods as indicated or at least give other people the impression that I didn't know what I was talking about. I suggested a condensation of network devices (based on the current scheme) into a fixed list of ethernet0, ethernet1 and so on, that would at once be different from the old default (the kernel names) and that would be executed moments prior to the activation of the networking system and that would fix the networking instability with about as much grace as the current system can foster. Meaning, I just wanted to map the current names into fixed lists (of devices) but only for hardware-devices-present-at-boot (unpluggables) and using the current "BIOS" names as the foundation for that mapping (in terms of order) such that the order of those devices would never change as long as the mapping was done after all the devices had been found. Which seems not impossible, but they told me it was. Existing mapping (renaming) to kernel device names caused race conditions when done on the fly. Mapping to another fixed namespace can never cause race conditions. And if the condensation is done prior to networking being started, there can never be an issue because conceptually networking cannot start until all required devices have been found. Ie. you cannot start some firewall if one of the required devices is missing. It is a complete and conceptual end-point (target, as per systemd jargon) that network device recognition must have completed prior to doing anything with those devices; that logically the former phase must be completed before the next can start. So how you can start networking while accepting as some kind of basic reality and possibility that 3 hours down the line, a required networking device will suddenly surface, is beyond me. Yet this is what Martin Pitt and others told me. Which to me feels like "find reasons to not have to do this thing, quick". "Give him the wrong directions, quick". "Don't let anyone think his idea is actually capable of having life, quick". :-/. What else can I make of it. Sorry for not writing all that well. Regards. </blockquote> <div style="bottom: auto; left: 771px; right: auto; top: 111px; display: none;" class="translator-theme-default" id="translator-floating-panel"> <div title="Click to translate" id="translator-floating-panel-button"></div> </div> </body> </html>