Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
* Marco d'Itri <md@Linux.IT> [170710 13:12]:
> On Jul 10, Adam Borowski <kilobyte@angband.pl> wrote:
>
> > Predictability is important, thus let's actually have _predictable_
> > interface names. The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that? Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of
> them will have appeared.
> Please stop beating this long time dead horse.
This has been discussed on debian-devel in the past, but this is the
first time that many of our users have seen this. This horse is very
much alive, just locked in the barn without food.
Neither you, nor any other proponent of the new scheme has addressed the
fact that short, easily remembered names in _all_ cases is significantly
more important than not having a state file.
The only benefit I have seen between the new scheme and the previous one
is that there is no state file. While getting rid of the state file is
a nice goal, it is extremely minor compared to having short, simple
names in common use cases like inserting a wifi usb dongle.
And no, enp2s0f1 is neither short nor simple. It requires remembering
three numbers and three letters that identify internal parts of the
hardware hierarchy that are irrelevant to the sysadmin.
With the previous scheme, an interface would be assigned a short, simple
name the first time it was seen. The sysadmin could easily edit the
state file to give it a more meaningful name, if desired. The state
file already had all the other information needed to identify the
interface; a simple one-word change in the file was sufficient.
Whatever name was in the state file was used for that piece of hardware
from then on. The names were at least as predictable as they are with
the new scheme.
With the new scheme, if I want to rename the interface to something more
meaningful, I have to go find an older machine that already has a
persistent-net.rules file or read through a lot of documentation to
figure out the correct syntax. I then have to determine the correct
ATTR elements to identify the interface in question, and type all of
that information by hand, hoping I type everything correctly.
There is an easy fix to revert the default behavior while still allowing
knowledgeable sysadmins to get the new behavior. On the other hand,
those who need to administer systems but are not sysadmins by trade (and
thus will have to do significantly more research to even know that the
older behavior is possible) are the ones who need the older behavior as
the default.
...Marvin
Reply to: