(no commit message)
authorLennartPoettering <mzninuv@0pointer.de>
Mon, 7 Jan 2013 21:29:02 +0000 (21:29 +0000)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 11 Dec 2018 09:58:39 +0000 (10:58 +0100)
docs/PredictableNetworkInterfaceNames.moin

index 7c1e74527f36691631a5def6bdda5b3bd84b5fae..da2776a42f595f817ea29ffa8bbe7e6998a796db 100644 (file)
@@ -12,7 +12,7 @@ Another solution that has been implemented is "biosdevname" which tries to find
 
 Finally, many distributions support renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names.
 
-We believe it is a good default choice to generalize the scheme pioneered by "biosdevname". Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly.
+We believe it is a good default choice to generalize the scheme pioneered by "biosdevname". Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly. That said, they admittedly are sometimes harder to read that the "eth0" or "wlan0" everybody is used to. Example: enp5s0
 
 == What has changed v197 precisely? ==