[systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

I just want to add another opinion, but I am going to keep it really short.

1. I believe most users do not like the "enp5s0" scheme
2. I do not think there are any good reasons for making it the default.

As a single illustration, I will cite this reason from the website:

"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."


Now the entire change is solely due apparently due to, or for, systems
that have multiple nics all complying to a certain naming scheme such as
"eth".

What is really the amount of systems or proportion thereof that have
multiple NICs?

So I am not saying this solution is a bad solution, I am saying the
default is a bad default.

Any user running a system with multiple NICs should be willing and
capable of choosing and assigning these names.

The new biosdev scheme is so meaningless that mostly any user WILL want
to change this scheme to become something meaningful, but the obstacles
to it are too great currently for the regular user.

So we may have 5% or less of all systemd/linux networking users that
actually requires this.

The 5% or less that does require it is not the type of user that would
not be able to adjust the naming scheme.

Even if these biosdev names would be mapped by default to comprehensible
names such as eth0 and wlan0, it would be better for the vast majority
that does NOT have 2 NICs.

There is really nothing against working internally with these names. But
it shouldn't be the presentation.

"We believe it is a good default choice to generalize the scheme
pioneered by "biosdevname"."

How on earth can you believe it is a good default choice if it caters to
only <5% of users, while 95% suffer for it?

That is not something that could ever be a good default.

"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."

95% of users do not replace networking hardware.

Setting up firewall rules for multiple zones requires manual
intervention regardless, or a form of automatic intervention that could
also decide on, and configure a network name mapping.

So what problem did you really solve here?



Now you are causing 95% of users that really need to turn it off.

To create the system they like, but most of them won't do it, because it
is not an easy configuration option either.

At the very least create a configuration file where this is a simple
named option. And then, at the very least, don't turn it on by default.

And if it does need to be on by default, at least create a default
mapping to the old names for everyone.



Perhaps this is something for distributions to decide, but changing
something downstream always requires more effort.

I do not know how big the class of installations that benefit from it.
But to my understanding cloud instances and VPSes generally won't.

So why not cater to the majority, and for the minority create an easy
way to turn it on and map it to meaningful names?

I. turn it off by default, allow it turned on by simple config
II. turn it on by default, create good default mapping to meaningful
    names
III. turn it off by default, but make it a breeze to create the mapping

Those are really your options.

Currently:

A. It is hard to turn off
B. It is not instantly clear how to do the mapping

A user needs to read
https://www.freedesktop.org/software/systemd/man/systemd.link.html and
won't find any examples that actually allow mapping the biosdev names,
so any user now has to find the MAC address or Path just to return to
something meaningful.

So if BIOSDEV has benefits, why not use it as a thing to map against?

And, creating multiple files for multiple mappings is not a convenient
and easy thing to do. Why not allow for something that can do this in
one single file?

Why not:

enp3s0: eth0
enp3s1: eth1

as a simple file format?

Why not create something like that by default?

Now you have solved the randomness in kernel registration, while still
having the naming scheme everyone loves.

This is much too much work for any normal user.

The knowhow to turn the feature off is not readily accessible on any system.

Ideally this knowhow must be present in a config file.

"80-net-setup-link.rules" is not something you can remember.

Distributions can make the same choice, but cannot really change the
configuration file format, nor the mapping ability based on the biosdev
names. What you've done here simply makes no sense.

In law a judge would say that you have placed an unreasonable burden on
the majority of users; that requiring them to change this on their own
is unreasonable, given that the minority who does use multiple NICs are
already required to configure their system to a much greater extent.