On Fri, Jan 31, 2020 at 04:32:32PM +0100, tomas@tuxteam.de wrote:
On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote: >The primary drawback of this method is that in the common case of a >single-user home desktop system with a single NIC, the name "eth0" is >expected to Just Work for whatever NIC happens to be in the system at >the time. It's also fundamentally unpredictable for the same reason that you can't just rely on the kernel name in the first place [...]to work around. (And really, in the single user/single nic desktop case, the user doesn't even *care* if the installer configures eth0 or foo11See? I do care.
In context, Greg talked about the "common case". In the common case, for the purpose of actually designing an OS, the user doesn't care. In your particular case, for aesthetic reasons or whatever, you care. That's not the common case, that's the you case. The common case is that the installer configures the network and then it never gets touched again. The common case is that the user probably doesn't even know what the interface name is, or thinks it's something like "my wireless card", because in the common case the user shouldn't have to know.
When the persistent schema came up, I took interest in it, since I had hit the problem quite a few times and well, if someone solved it, I'd like to know. Once I understood it, my reaction was "meh".
You still seem to not fully understand it. (Specifically, the difference between "persistent" names and "predictable" names. One of the problems systemd was trying to solve was predictability in the absence of persistent storage at boot time, e.g., for initial installation, or for remote storage.)
but for me and my installations, it wasn't worth the more complicated names. I still do "sudo ifup eth0" and don't really want to do "sudo ifup &$#*@%#". I had seen those things before (was it Solaris) and -- oh well.
Solaris did it for reasons. Eventually linux tried to fill roles which required the same sort of solution for the same sort of reasons. "I don't want to" isn't a rational argument that anyone can address. If you just don't want to do it, then ok, but why share that with everyone?
Now dismissing folks who don't share your opinion on some shiny new thing as "just resistant to change" or "tinkerers" is a horrible antipattern. Please don't do that. It leads to ugly discussions and hurt feelings. Been there, done that.
So does dismising everything new as broken because it fixes things you don't care about.
The bottom line is that in most cases the predictable names "just work". In some corner cases something goes wrong, just like in some corner cases every preceding system went wrong. For the predictable scheme the most likely thing to go wrong is that you've got a system whose firmware is broken. Unfortunately that's really hard to fix. On the bright side there are workarounds and alternatives for those who need them or for particular use cases which aren't well suited to the defaults.
If you have some unusual requirement where you want the name to be one specific thing and you'll be unhappy if it's anything else, well, that can also be achieved! But it's certainly not something that needs to drive the common case defaults.