The Simple Things in Life
Markus Lankeit
mlankeit at gmail.com
Wed Jul 20 23:54:02 UTC 2016
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>
More information about the Ubuntu-devel-discuss
mailing list