The Simple Things in Life

[Markus Lankeit]

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 ( 
http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04).

Thx.

-ml


On 7/20/2016 1:56 PM, Xen wrote:
> Markus Lankeit schreef op 20-07-2016 0:01:
>
>> 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"?
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20160720/e4161224/attachment.html>