Having dealt with systems with half a dozen interfaces in the past there's
a very small number of cases where it even matters, but when it does, it
can be a huge inconvenience either way.

Their (for once, rational) argument is that Interface names of existing
interfaces should never change by adding or removing hardware from the
system, or as a result of hardware/software quirks (on some systems,
interfaces are known to swap places on reboot, which is clearly not
acceptable).

There are numerous approaches to dealing with interface names - off the top
of my head I can come up with the following

1 - detect the current name by mac address and use shell script variables
to deal with it.
2 - have udev issue automatic persistent names by bus location
3 - have udev issue automatic persistent names by mac address
4 - have udev issue manual (admin-chosen) persistent names by bus location
5 - have udev issue manual (admin-chosen) persistent names by mac address
6 - do nothing, blindly use the traditional interface names and hope it
doesn't break due to some event reordering the interfaces
7 - detect the current name based on what other devices are visible via
each interface / which devices can reach the internet
8 - name interfaces by driver family (IIRC, default behavior of some *BSDs)



Bus location is a sensible default in newly installed systems, because it
provides reasonable guarantees that names won't shift on their own. It
shouldn't automatically change from traditional names to these names on an
installed system though, because then you've just caused the very problem
you are supposedly trying to solve.

Dealing with possibly shifting interface names in firewall scripts is
certainly an option, but dealing with it in udev is far more elegant, and
in the long run, much friendlier to the admin. It's easy to fix these names
to an admin-defined name by bus location or mac address as needed






On Sat, Jan 9, 2016 at 11:03 AM, dev1fanboy <devuanfanboy@???>
wrote:

> It sounds like a good idea in theory, but I see no reason eth0, eth1,
> wlan0, wlan1, etc should change. It could be as simple as deciding which of
> those to use based on some information from the device in the case there is
> more than one NIC. Changing that for no good reason is clearly a bad idea.
>
> Personally, I'm not buying it. Freedom to choose and backwards
> compatibility is more important to me [not for sale].
>
> On Saturday, January 9, 2016 11:41 AM, Anto <aryanto@???> wrote:
> > Hello Everybody,
> >
> > I have just rented a KVM VPS. I started with Debian squeeze, pin
> > everything related to systemd to -1, then upgraded to Debian wheezy.
> > After I upgraded udev to version 220 using eudev, I could not connect to
> > my VPS any more after reboot. This has never happened on my other VPS'
> > but they are all Xen-PV based VPS.
> >
> > It turned out that the eth0 interface was changed to ens3, due to the
> > implementation of Predictable Network Interface Names
> > (
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
> ).
> > I can change everything which contain eth0 into ens3, but I prefer to
> > keep the old interface naming. So my temporary solution is to add
> > net.ifnames=0 into the kernel command line.
> >
> > I have been indoctrinated myself that everything come from systemd gang
> > are stupid and bad. After reading the above link and some other pages
> > from systemd supporters, I think I might have to change my mind about
> > that Predictable Network Interface Names idea. But I am not entirely
> > sure yet. What do you guys think about that?
> >
> > Kind regards,
> >
> > Anto
> >
> > _______________________________________________
> > Dng mailing list
> > Dng@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> --
> Take back your privacy. Switch to www.StartMail.com
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>