Linked by AdamW on Thu 27th Jan 2011 22:10 UTC
Fedora Core 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.
Order by: Score:
And...
by darknexus on Fri 28th Jan 2011 03:58 UTC
darknexus
Member since:
2008-07-15

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?

Reply Score: 3

RE: And...
by Soulbender on Fri 28th Jan 2011 04:16 UTC in reply to "And..."
Soulbender Member since:
2005-08-18

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.

Reply Score: 3

RE[2]: And...
by avgalen on Sat 29th Jan 2011 06:05 UTC in reply to "RE: And..."
avgalen Member since:
2010-09-23

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

Reply Score: 1

RE: And...
by gilboa on Fri 28th Jan 2011 07:18 UTC in reply to "And..."
gilboa Member since:
2005-07-06

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

Reply Score: 3

RE[2]: And...
by B. Janssen on Fri 28th Jan 2011 10:33 UTC in reply to "RE: And..."
B. Janssen Member since:
2006-10-11

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?


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 ;)

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.


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.

Reply Score: 2

RE[3]: And...
by gilboa on Mon 31st Jan 2011 20:43 UTC in reply to "RE[2]: And..."
gilboa Member since:
2005-07-06

Well, yes. That you are mucking around in individual interface configs shows me that you missed the point of persistent-net.rules.


What makes you say that?
(See the comments below)

Then again, I don't find reading lspci output that hard ;)


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.

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.


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


I believe you have completely mis-read my OP.

- Gilboa

Edited 2011-01-31 20:44 UTC

Reply Score: 2

RE: And...
by Nth_Man on Sat 29th Jan 2011 19:26 UTC in reply to "And..."
Nth_Man Member since:
2010-05-16

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

Reply Score: 1

Comment by sb56637
by sb56637 on Fri 28th Jan 2011 04:56 UTC
sb56637
Member since:
2006-05-11

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

Reply Score: 3

RE: Comment by sb56637
by gilboa on Fri 28th Jan 2011 07:13 UTC in reply to "Comment by sb56637"
gilboa Member since:
2005-07-06

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

Reply Score: 3

Comment by rafaelnp
by rafaelnp on Fri 28th Jan 2011 13:26 UTC
rafaelnp
Member since:
2009-06-03

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

Reply Score: 1

RE: Comment by rafaelnp
by Neolander on Sat 29th Jan 2011 17:56 UTC in reply to "Comment by rafaelnp"
Neolander Member since:
2010-03-08

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

Reply Score: 1

See Slashdot
by zimbatm on Fri 28th Jan 2011 14:18 UTC
zimbatm
Member since:
2005-08-22

For once, I think slashdot comments are insightful

http://linux.slashdot.org/story/11/01/26/0252220/Fedora-15-Changes-...

Reply Score: 1

maybe itll be better
by TechGeek on Fri 28th Jan 2011 14:44 UTC
TechGeek
Member since:
2006-01-14

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)

Reply Score: 2