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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel