:: Re: [DNG] What does Linus do?
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Simon Hobson
日付:  
To: dng
題目: Re: [DNG] What does Linus do?
Adam Borowski <kilobyte@???> wrote:

> It would mean changes to every single program that deals with network
> interfaces. With renaming, you apply this in a single place.


This.
If an interface name changes, I don't want to have to find and change every occurrence - network config, firewall/iptables rules, dhcp server, data collection scripts (eg grabbing interface stats), and ... With a quick look, I see that some of my Nagios plugins need the interface specifying.
And don't forget that external systems may have visibility/use interface names - eg via SNMP.

And as pointed out, this is a very different situation to filesystems/disk drives.
With disks, you have a level of abstraction inherent in the filesystems layout. Few things work with disk/partition names - so provided mount and fstab between them can describe what mounts where, then nothing else in normal use needs to know anything about names - they just refer to files. Pretty well everything that refers to disk/partition names is something run manually by the admin.


ISTM that there are in fact two distinctly different cases being talked about - and those use cases have different needs which I think may be part of the problem in trying to solve everything in one way. Or, there seems to be a lot of discussion about what size & shape the hammer should be, forgetting that "if the only tool you have is a hammer, then every problem looks like a nail".

I'd suggest (no I don't have any references) that the vast majority of systems, especially those not managed by a "professional admin", have just one ethernet NIC and/or one WiFi interface. For these systems there is no problem just using the default kernel option that names them eth0/wlan0.
Furthermore, for these systems, all the "solutions" to the non-existent problem are actually creating a problem that didn't exist.

Then I'd suggest that the majority of systems with multiple NICs are managed by someone "with a clue" - and for these the problem was solved years ago with techniques to rename interfaces (my preference being to use meaning names like ethlan, ethext, etc which don't clash with the defaults).


So that doesn't leave many systems with a problem to solve !