> I'm clearly in the minority here, but in what way is something
> anonymous like "net0" any more intelligible than "e1000g2"?
The point is that it's not tied to the whim of the computer manufacturer.
> I see no advantage here. I've been lumbered with this sort of
> random naming scheme elsewhere and it's a real PITA.
It's not random; what we have is random. That said, if you don't like it,
you can simply name your links back to e1000g2 or whatever. It's just a
default.
> So what determines the numbering scheme in a system with multiple
> interfaces (in particular, the order in which they're enumerated)? If I
> primarily use wireless, does that end up being net0?
The order is unspecified but will not change after initial enumeration.
Today, if you have two e1000g's on a given machine, they will enumerate as
e1000g0/e1000g1 (and if the hardware folks did things right, that
enumeration will match the "0" and "1" labels on the back of the box). In
the future, those will be net0 and net1. Administratively, it's as if all
datalinks are supported from a single driver named "net".
> It seems to me that there's a fundamental weakness that needs to be
> addressed. If users are doing low level admin stuff that requires them
> to know the name of the device - even if that name is net0, then we've
> lost.
Most systems require some network administration, whether it be GUI or CLI
based. Those administration tools need some handle to refer to the
system's network interfaces[1]. We'd like that handle to be clear and
consistent, and for the handle to still apply when e.g. network hardware
is replaced, or more sophisticated topologies using aggregations, VLANs,
VNICs, or tunnels are deployed. Again, we generally encourage admins to
name datalinks as appropriate (see the howto link in my original post);
the netN name is only a default.
[1] Note that e.g. the current NWAM mock-ups also provide a description
of each interface -- such as the vendor and chipset -- but unlike
the current chipset-based names, this description doesn't end up
leaking into network configuration like IP filter rules.
--
meem
