Re: Silly question: Where's eth0?
El vie, 26-10-2007 a las 17:46 -0400, Douglas A. Tutty escribió:
> On Fri, Oct 26, 2007 at 07:16:03PM +0100, Joe wrote:
> > Yes, I know what to expect with Sid, which I've been running since
> > before Sarge was released, and this isn't it. Sid is for incorporating
> > new software variants into a future Stable, and sorting out any
> > integration issues, not for troubleshooting broken software. It's
> > supposed to work *before* it arrives in Sid.
> > I had one (1) Ethernet adaptor, which used to be called eth0. I can
> > understand potential confusion if there was more than one, and I've seen
> > that happen. What conceivable reason is there for designating it eth1,
> > the second Ethernet interface, when the machine contains only one?
> > Workarounds there might be, but why do I need them?
> > The thread is about the wisdom of setting up networking in The Debian
> > Way. The point I was making is that The Debian Way today clearly isn't
> > The Debian Way of a month ago. It used to involve editing a text file,
> > and at worst tweaking the modules a bit, now it involves learning the
> > operation of an entirely automatic system that the user isn't even
> > supposed to see, and how to override it when it screws up. As far as I'm
> > concerned, that's The Windows Way, and it doesn't belong in Linux.
> Here Hear!. However, your anger is misdirected. Udev is part of the
> 2.6 kernel not part of Debian. If a new version of udev comes down the
> pike to go with a new version of the Kernel, don't blame Debian. Sure,
> I suppose they could stall brining a new kernel into Sid until udev was
> fixed but my jaundiced view is that udev will never be fixed it will
> just continue to make Linux look more and more like windows; Lindows.
Well, after the addition of SEWindows in Debian, udev and others; maybe
Debian needs its own kernel, as BSD! Because if not, it is going to be
> I wish it was more like OpenBSD where there are no eth*, but numbered
> instances of drivers by name. I _think_ the order is based on hardware
> (e.g. what PCI slot its in) and so doesn't flop around like udev does.