Dan Portscurrently attempting to use an ethernet interface called "enp8s0f0npf0vf1" and cannot help but think
STATEMENTS DREAMED UP BY THE UTTERLY DERANGED
THEY HAVE PLAYED US FOR ABSOLUTE FOOLS
Rob Carlson 
@dan Beats the hell out of “I hope card 1 gets picked up in the remote reboot order before card 2 so it becomes eth0 and my firewall inside doesn’t become my firewall outside.”
Daniel Gibson@vees @dan
if only there had been ways to identify a network card and store its ethX name from first boot and keep on using that unless the user explicitly changes the name(s) - must've been impossible.
clearly easier to generate a name that's "predictable" (by some definition of predictable) and, depending on the naming scheme used, hard to impossible to remember -_-
if only there had been ways to identify a network card and store its ethX name from first boot and keep on using that unless the user explicitly changes the name(s) - must've been impossible.
clearly easier to generate a name that's "predictable" (by some definition of predictable) and, depending on the naming scheme used, hard to impossible to remember -_-
leo vriska 
@Doomed_Daniel @vees @dan according to systemd docs they briefly did this but stopped because it turned out that in some cases the kernel and udev could race to assign the same
(and also apparently there's a surprising amount of systems where the MAC address is randomized on each boot?)
ethN to different devices and it would massively break things(and also apparently there's a surprising amount of systems where the MAC address is randomized on each boot?)
Matt Palmer@leo @Doomed_Daniel @vees @dan so, to recap:
1. Everything was fine.
2. Systemd arrived.
3. Everything was broken.
4. Rather than just throw systemd back where it belonged, everything had to be made terrible in the name of progress.
1. Everything was fine.
2. Systemd arrived.
3. Everything was broken.
4. Rather than just throw systemd back where it belonged, everything had to be made terrible in the name of progress.
@Doomed_Daniel @leo @vees @dan 70-persistent-net.rules solved the problem nicely. In two decades of managing a great many systems that had a great many NICs in a wild variety of configurations (yay 802.1q over bonding!) not once did "my eth0 is now my eth1" ever cause any problem.
But now, I can't assume that my sole NIC will be called eth0, and instead have to cut and paste from the output of 'ip li sh' every time, because a bunch of nitwits had to incompletely solve a non-existent problem.