Guest post by Fedora is holding a Test Day tomorrow (2011-01-27) to test a new network device naming scheme, as implemented by the biosdevname utility provided by Dell. biosdevname aims to give network interfaces names that are both consistent and appropriate to their physical attributes (onboard device number, or PCI slot), an approach that has been kicked around upstream for a while. This new system will likely come to most distros in future. The Fedora test day will concentrate on making sure it behaves as intended on both new installations and upgrades.
It will be years before everything is compatible with the new naming scheme, and commercial software will not be compatible for another five years (remember how long it took for VMware to even get ALSA support?). This is an example of change for the sake of change, not because it’s actually necessary. And we wonder why we’ve not seen the rise of the Linux desktop in the mainstream? Tell me, how far do you think Windows would’ve come if Microsoft had made major interface changes every two years and broke everything?
You mean like all the major interfaces changes they always do and the resulting mess of backwards compatibility they implement to keep everyone happy?
Seems to have worked out pretty good.
Since Windows 95 and NT 3.51 only two major changes have happened:
1. The end of the 95-98-98SE-ME line and merging into 2000 (NT 5)
2. Major driver changes in sound, display and network infrastructure between XP/2003 and Vista/2008
We can safely assume that everyone agrees that the first change was for the best and that backwards compatibility was needed. It took until XP SP2 before everyone agreed that this change was actually for the better though.
The second change didn’t go so well and took the first service pack and especially Windows 7 for people to realise the changes were actually for the better
So no, MS doesn’t change all the time, backwards compatibility isn’t as big a problem as people often make it, all changes were indeed for the better and it didn’t always work out so well in the beginning
Even tried to explain to a sysadmin how one should look at lspci in-order to locate which devices are PCI and which are on-board so he/she will be able to understand which lines in each and every /etc/sysconfig/if-cfgX file and each line in /etc/udev/rules.d/70-persistent-net.rules should be changed just so two servers, each with multiple 1GbE and 10GbE cards, but with different firmware version will have the same device mapping? No?
… I’d give it some thought -before- calling this change a change for the sake of change, OK?
Plus, in the age of virtualization and high-performance networks assuming that a machine only has ethX devices (as opposed to ethX, brX, virtX, tapX, etc) is plain wrong.
Oh, and –please– don’t get me started about the mess that is called “Network device naming convention” under Windows.
I literally wrote a software that uses winpcap and reads various registry keys just to give the admins something that makes it remotely possible to understand which UUID belongs to which device. At least in that respect Windows is a bloody mess.
– Gilboa
Edited 2011-01-28 07:34 UTC
Well, yes. That you are mucking around in individual interface configs shows me that you missed the point of persistent-net.rules. Then again, I don’t find reading lspci output that hard
And the point would be? The suggested change is only concerning hardware NICs, not bridges, tunnels or virtual devices. Dell’s little tool is not touching those.
I respect your anguish, GNU/Linux can be frustrating — it certainly frustrates me from time to time — but you seem to be confusing some things here.
What makes you say that?
(See the comments below)
Neither do I.
… But try explaining to a Windows admin how to sync persistent-net, if-cfg and lspci and you’ll understand why this feature is -long- overdue.
You have completely misunderstood my point.
My point was:
1. Giving network device according to their location (on-board, PCI-slot, etc) is a must when dealing with machines with large number of NICs.
2. Claiming that using non-ethX names will break modern network applications is absurd, given the large number of non-standard names being used today (brX, virtX, tapX, etc)
I believe you have completely mis-read my OP.
– Gilboa
Edited 2011-01-31 20:44 UTC
> Linux desktop in the mainstream
For your information, Linux != Fedora.
There are distributions, and if even the same Red Hat has planned the change first for Fedora (not for their other distributions), it’s for a reason.
Sweet, now the network device names will be as simple as the partition names. So now we can run like:
ifup z1b635de-d3c7-46c3-m14e-4e976f15k2q4
Bullshit.
Had you bothered to look at the actual link instead of simply spreading FUD, you’d notice the that new naming convention tries to to force some login into the selection of device names, e.g.:
– Embedded devices: emX
– Add-in PCI cards: pciX#Y_Z
All of this marks an amazing improvement over the current situation where I’m forced to manually edit the ifcfg-ethX files and rules.d/70-persistent-net.rules in-order to force some sense into the device naming selecting on servers with two on-board 1GbE ports and multiple quad 1GbE / dual 10GbE NICs.
– Gilboa
What a waste of time. The are more important things to solve and/or improve. For example, yum IMHO, is very slooooooooooow. It could be rewritren in C or C++.
The version in F14 works nearly as fast as APT on my laptop.
What’s an absolute no-no, on the other hand, is the PackageKit (I think) mess : they didn’t manage to make yum lock-free, so what they did was to queue everything instead of displaying “Sorry, lock is busy” messages. Net result : from a user’s point of view, GUI package manager sounds hanged instead of just saying that it cannot work. And this new way of doing things allows new kind of crashes : I’ve managed to deadlock two instances of yum once, though I didn’t manage to reproduce it later.
I can see a few cases where this might be useful, but frankly they should leave it as an optional feature for sysadmins and work on a package manager without a big lock instead.
Edited 2011-01-29 18:00 UTC
For once, I think slashdot comments are insightful
http://linux.slashdot.org/story/11/01/26/0252220/Fedora-15-Changes-…
While I will miss the simplicity of knowing that on any machine the first network device will be eth0, it may fix a few things. Its always a pain when you have multiple NICs in a machine and they come up in different order during startup. Being able to specify a device and always get the same one will be nice. (Note this isn’t a linux bug AFAIK, just the bios being flaky about starting devices)