Steve Litt <slitt@???> wrote:

>> The whole point of having 'an operating system'
>> is that it provides an abstract interface userspace software can use
>> to interact with the physical components of a different computer
>> according to the functions they're supposed to be provide, regardless
>> of the way this particular computer happens to be assembled.
>
> Does anyone else agree with me that in the preceding sentence Rainer
> encapsulated the entire philosophy of people desiring simple and
> logical software? Rainer, can I quote your preceding sentence elsewhere?

It seems a good summary to me.


>> Considering this, encoding details of the bus layout and current bus
>> configuration in network interface names is just profoundly stupid.
>
> I thought it was stupid for other reasons, but now that you mention it,
> yeah, naming it after the particular slot into which it's plugged in is
> stupid, and if you take the box apart and move things around, you can
> break your OS.

Unfortunately, I think this is one of those areas with no right answer - only different levels of suckiness.

Constraining "the system" to always loads drivers in a specific order, and hence not randomly rename interfaces at boot time is wrong.

Using stupidly long/complicated device names based on physical location is wrong. Doubly wrong when location can be highly variable (as in USB devices)*

Using stupidly long/complicated device names incorporating the device serial number (or MAC) is wrong.

Using persistent rules files (as with Udev) is wrong.

However, I am happy with the way Udev does it. Booting a "new" system results in an initially random device ordering, but once it's created a rules file the devices stay stable until "something changes". When changing hardware, or shifting the image to new hardware, new devices get created and the admin needs to "fix" it - but TBH it's not hard to do.
IMO - the sort of person who cannot edit the system created rules file is also not likely to be running the sort of system where it matters. Eg, they are likely to be the sort of use who plugs a cable into a hole in the back of the computer, and "the system" takes care of enabling it and getting addresses via DHCP/autoconf - the user doesn't care if it's eth0, eth57, flurbleport29, or anything else as long as "the network works". If for some reason they replace a network card, it's not likely to matter to them that eth0 is now called eth1 - as long as "it just works".

I don't tend to use ethn anyway on bare metal systems - they all have Udev rules to set meaningful names like ethext, ethlan, ethint, and so on. Different on my Xen VMs (Debian [Sarge** ... Wheezy] as out of the box there doesn't seem to be a Udev rules file created and it's never bugged me enough to figure out why !

* I've only hearsay evidence from the screams of colleagues, but it seems that some Windows stuff (in this context, setting up automated backups) is sensitive to which port the disk is plugged into. As in, if the user plugs the backup disk into the wrong USB port, it gets a different drive letter (how 20th century !) and the backup (which uses drive letter and not anything more sensible) fails.

** Yup. still got one of those running !


There is something of a parallel with filesystems/disks - where the results of "getting it wrong" are more significant. I recall back when I had "a bit less experience" and the problem was fairly new, having issues with a system where disks came up in random order during boot (two different controllers). Now I generally use disk (filesystem) labels - though it's "annoying" that Debian doesn't support filesystem labels for Grub - which have the advantage of having their own persistent storage attached to the device, but the same problems when moving things around.
It certainly needs a little care when identifying disks/filesystems by label in Xen VM configs.