Date: Sat, 8 Apr 2006 16:39:38 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers.102a7e@mired.org> To: Scott Long <scottl@samsco.org> Cc: hackers@freebsd.org, Ceri Davies <ceri@submonkey.net> Subject: Re: Using any network interface whatsoever Message-ID: <17464.8074.937742.701480@bhuda.mired.org> In-Reply-To: <443811EF.2020509@samsco.org> References: <C05CAC06.C0BD%ceri@submonkey.net> <20060407225742.GA21619@odin.ac.hmc.edu> <20060407230247.GH16344@submonkey.net> <4437C9F6.5000008@samsco.org> <17463.65076.117616.563302@bhuda.mired.org> <443811EF.2020509@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In <443811EF.2020509@samsco.org>, Scott Long <scottl@samsco.org> typed: Please trim the text you are repling to. > You're argument here doesn't really make sense. Only because you're carrying it to ridiculous extremes and misinterpreting it. > Youre' saying that > instead of /dev/da0, we should have > /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 That's a ridiculous extreme. All I advocated was that we be able to easily identify the devices connected to the system, *not* that we be able identify every device in the world. Sun solved disk device naming back in the 80s. > and instead of em0, it should > be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? This is a misinterpretation, because you're including system configuration information (the network it's attached to) in the device description. I'm not aware of a good solution to this problem for ethernet devices. > I'm not saying that we should get rid of the device information. I'm > fully happy making it available to top layer applications. > Administrators definitely need the information to make good decisions. > But the information isn't always needed, and it does make simple > management tasks harder. I think I said that. > It also adds complexity that can lead to > problems. Why when I add a RAID driver do I also need to hack up > sysinstall so that it'll recognise the RAID devices? Missing features in sysinstall would seem to be irrelevant. > The computer should be helping us in administration tasks, not > hiding behind inconsistent and obscure names. All names are obscure when you don't know what they mean. And once you know what they mean, they aren't obscure any more. Which doesn't mean the computer can't help us deal with things. The current BSD device naming and management schemes date back to at least v6. Updating them to deal with modern conditions, as opposed to those that were prevelant in the 70s, is certainly a reasonable thing to suggest. But the Linux solution of smashing all the devices of the same basic type into one flat undistinguished namespace is *not* an improvement. > Now, for your specific case of SCSI, it is possible to wire down device > assignments by the administrator. It's been documented how to do this > in man pages and kernel config files, most recently by me personally, > for years. I know. I figured all this out and documented it when it happened to me years ago (I did say it was a 4.x system). It's still a suprise when adding new hardware breaks the configuration of old hardware on a system as reliable as Unix usually is. I expect that from Windows, but not Unix. > The flaw is that it still requires specific operator intervention to > make work. That's the flaw, all right. The *problem* is that the system was trying to be user-friendly in ill-considered ways. Again, this is the kind of problem I expect to run into with Windows, not Unix. > That's where things like volume labels come > in. Does a sysadmin care about the low-level device name for a drive on > a Windows or Mac system? Does he even know without taking a deep look > inside the system? Does not knowing it make it any less possible to > easily and reliable manage and control the hardware? On the Mac, the answers are "yes", "yes" and "not applicable". On Windows XP, the answers are "yes", "no", and "yes". > It's all done through human-readable labels that are easy to work > with. No, it isn't. *Most* of it is, and probably everything that the casual user runs into. But we're talking about sysadmins, who have to deal with issues like unformatted drives and file systems that don't necessarily have labels. Oddly enough, on the Mac you tend to get things that look like your ridiculous disk name when dealing with these (i.e. "93.2 GB ST9100823A"). > The low level information is still available when needed, but it's > not the primary means of control. I think that's fine; it strikes > the balance between control and ease of use that I'm looking for. Volume labels would certainly solve a lot of issues - even some of the ones I brought up. In particular, if they became the standard way of dealing with devices, then we could unravel some of the more user-friendly-but-expert-hostile designs already in place. But where do you put the label on an ethernet interface? <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17464.8074.937742.701480>