On 02/03/11 14:14, frantisek holop wrote: > hmm, on Wed, Feb 02, 2011 at 10:24:55PM -0500, Nick Holland said that >> problems which are easy to fix. Having worked with similar problems >> (and their recovery) on other OSs...ick. > > talking about other OS's and risking making a fool of myself, > what do the others think about the new scheming fedora plans > to implement? [1]
too complex. And...at the moment, a one-trick pony (or more accurately, a one-pony trick). We'll see if it gets adopted by the rest of the Linux world, so it can be a LINUX way of doing things instead of a single distro's way. > disks have solved their ambiguity, DUID's are great. > a unique identifier is not necesseraly helpful for a nic > in this case however. and in many cases, I think the DUIDs are too complex, too. Most of my systems will continue to have disks which are identified only by sd0x or wd0x. Where the DUIDs solve a problem (flash drives, my netbook which backs up a "critical" directory to a SD flash card on boot, which may "move" depending on what else is plugged into the machine), I'll happily use them and be grateful for them, but I'm not going to replace /dev/sd0a with 4b8432d7819c0c85.a just because I can, it has to improve the system. 4b8432d7819c0c85 is completely non-intuitive, non-typeable and non-memorable to me, and the ".a" at the end is too easy to lose in the jumble. DUIDs have a definite cost. If it makes my life easier (bootable flash drive, netbook backup thingie, some softraid configs), great, I'll happily pay that cost, but not if I don't get a clear return. > now, however <insert your opinion> that scheme might be, > there is a certain logic to it. absolutely. just like the certain logic in the OpenBSD system or the MAC-tied system. > the physical placement > of the card (esp in the case of replacing a faulty one > is the ultimate word regarding that nic's role in the > given machine. unless, of course, you don't have the same card on the shelf, in which case maybe you end up sticking a different card in a different slot (i.e., replace a PCIe card with a PCI card) and then...back where we were before. OR...your replacement machine is a bit different than the production machine. Or it turns out the slot is bad on the machine. Or there's a cable in the way that makes getting the card back in where the old one was difficult. Or the case was causing the old card to pop out of the slot and you figure you should move the card to another slot. OpenBSD lets you get away with that pretty easily, especially if you have different families of NICs in place, but things could move around unpleasantly in the Fedora plan...after you were told that it wouldn't happen and have no idea what to do when it does anyway. Yes, my scenarios here violate my "have compatible spare hardware on hand" rule. You were hoping to have a new job before it blew up on you... :) > i always pereferred the openbsd naming to linux's > because one can put a "face" to the nic, it's not just eth[0-9]. > it is esp. useful if cards are mixed in the box :] > (e.g. rl is outbound, re inbound, etc) yep. resorted to this more than once myself. Easier than reading my hand-written MAC addresses on the spine of the card. :) Used to live by it in the ISA days, as every NIC had its own rules for identifying (and scarily enough, I knew most). (and yes, I often catch myself doing the Ricer thing of trying to optimize which NIC faces which network, even though in reality I know neither will be nearly saturated, so the real world difference will be absolutely zero) >> A much better solution to your original problem would be to have spare >> parts on hand enabling you to replace the failed re0, in which case you > > so it's not enough that you are in great stress because of the outage > and you need to replace the faulty card(s), you have to make sure > it uses the same driver as well? :] well, yes, the idea of spare hardware is that it be swappable with the failed hardware and Do The Job. But, if you widen the scope from "compatible" to "sufficient to do the job with a bit of intervention", then yes, you could have problems with OpenBSD here. Or Fedora, as indicated above if your "sufficient" card requires installation into another slot (planned or unplanned). > i am sorry but this seams to me > as the parallel case of "policy problems shouldnt be solved in > software" applied here on the hardware. the ideal state would be > just to replace the card and be done with it (of course this still > wouldn't work if an embedded nic needs replacing with an external one) If you are in great stress over an expected failure mode, you are doing something wrong...and it happened long before the NIC failed. Hardware fails. Be ready for it. Save stress for unexpected modes of failure ("uh... how did we not notice we were building the new data center right under the executive kitchenette?" "You mean where the pipe just failed?" "yeah, that one") btw: my solution covers the on-board NIC failure, too -- that's covered by replacing the whole computer, or at least the main board. When NICs fail, they sometimes get really hot...the rest of the computer may not be far behind the failed NIC chip. ALL hardware can fail. Be ready for it. Hey, the Fedora plan solves a problem. The other linux "tied to MAC address" system solves a different problem. The OpenBSD system solves some problems. They all introduce certain OTHER problems. The OpenBSD system is REALLY SIMPLE and easy to explain and easy to untangle when things go wonky. I like that in a solution, as problems are often much more complicated than people expect. When NICs change in OpenBSD, I expect there to be (minor) issues, I fix and move on. When NICs change in other systems which are supposed to "save me" from the OpenBSD-style problems, I usually find my problem was far more complicated than imagined by the developers, causing more delay in recovery than I'd like. Hopefully, I've figured out how the other systems work well in advance of The Event. Nick.