Nate Bargmann <n0nb@???> wrote:

> After I thought about it some, there is a certain logic to udev's
> behavior but it would seem to make more sense if the network adapter is
> on a hot-pluggable interface (PCMCIA, USB, etc.), or is in addition to
> the adapter already assigned to eth0 on a PCI bus. The behavior of
> assigning eth1 to a new adapter on a PCI bus where the old adapter no
> longer is present

Unfortunately, absent the "admin mind reading" kernel module, I doubt this can ever be solved for everyone. For me, the standard udev way of doing it works - it's simple enough, and easily enough managed as long as you remember to edit the file when you change hardware. I have "unfond" memories of working with a box in the past where the interfaces came up in seemingly (to inexperienced me) random order such that I'd be using eth0 during install, then when I booted the installed system I found eth0 didn't work and I should now be using eth1 - but if I booted from the CD for maintenance (I learned a lot from breaking things !) then they'd swap back again.

Clearly this doesn't suit everyone - and as things stand now (or at least, sans-systemd) it's fairly easy to fix things up yourself (eg don't use udev and sort out module loading order yourself).

But as I see it, sorting out one entry in udev rules is simple enough. Anyone who thinks that changing the interface name in a hard manner, such that you have to find and edit every place you used it - network config, firewall config, utility scripts you've written, data logging scripts you've written, ... - is a complete and utter clueless numpty.
Oh, that's exactly what systemd and the new udev forces you to do.