[lfs-support] Ethernet Card Not Found

Bruce Dubbs bruce.dubbs at gmail.com
Tue Nov 26 11:27:26 PST 2013

akhiezer wrote:
>> From: Simon Geard <delgarde at ihug.co.nz>
>> To: lfs-support at linuxfromscratch.org
>> Date: Tue, 26 Nov 2013 21:05:53 +1300
>> Subject: Re: [lfs-support] Ethernet Card Not Found
> 	.
> 	.
>> But really, what's wrong with it? All the melodrama, talking about
>> "abominations" and complaining about Lennart breaking things - but
>> what's actually wrong with it, that makes that 1% solution a problem for
>> you?
> I think at least some patently obvious answers to that are in this and similar
> threads - e.g. the pointless hassles caused to all sorts of folks, for no gain,
> from new 'wonder' 'solutions' that will be thrown out - and in this case are
> already being partially thrown out right now - in favour of the next magic
> bullet; and so on and on.
>> Because it's not something I'd even notice - I've no idea what the
>> network device on this machine is called, because I've never needed to
>> know it, other than when I first set it up an age ago. What do you do
> What method do you use for e.g. firewalling rules, if any, on that machine? Do
> you use device names that are gotten/updated dynamically so that you never
> 'need' to know them, and reliably so that you're not left with an open
> 'firewall': or d'you have a similar method for using IP-addresses only, that
> can adapt dynamically to different networks? Or d'you not use any firewalling on
> that particular machine; or what? It's an intriguing concept - *never* needing
> to know the name of network device(s) on one's Linux computer, and for someone
> like yourself who would appear to be an (>=)advanced user.
>> differently, that the new naming convention can annoy you so much?
>>From here, it's not really annoyance: it's more contempt for the, at base,
> intellectual inanity of much of the attempts at solving 'dynamic-environment'
> issues in Linux (e.g. udev/*Kits/&c&c&c). And even moreso for the behaviour of
> various 'characters' who push this stuff as if it is a ready solution, when
> instead it's at best half-baked. Too many distros - who are not intentionally
> positioning themselves as overtly bleeding-edge - adopt and push it too in the
> same manner. And so the inevitable add-ons and bodges and fixes and changes of
> approach from upstream, and eventual abandoning of it in favour of the new
> flavour-of-the-period, are essentially all being carried out in-situ in the
> 'working' OS on folks' computers: those users are essentially being led - and
> pushed - around by the nose.
> Also do spare us the disingenuous "what's the problem" nonsense. There is a
> well-known context and wider picture to all this stuff. One of the central
> problems is that there are characters prominent in the Linux landscape who are
> behaving in ways that are similar to those who would _enslave_ others if they
> can get away with it: you let yourself be frog-boiled if you like; not everyone
> will sleepwalk into it, though. There are characters prominent in Linux who -
> presumably/hopefully not quite realising the historical and geographical
> resonances - advocate the burning, not quite of books, but of printed matter.
> The linux kernel is routinely released with the statement, "All users of the
> x.yy kernel series must upgrade.": even allowing for differences in
> first-language and possibly context etc, what sort of garbage is that -
> "must upgrade" ?
> We're all for genuine improvements, and have adopted here a lot of new things
> in Linux: but have also, in an informed procedure, rejected one 'magic bullet'
> after another as they came and went, simply because ... they're not very good.
> And a lot of the stuff that's causing the controversies over the past few
> years, are just _not very good_: _that_ is the main problem.

The wording in this message comes across a little too strong.  Yes, we 
sometimes get a little emotional about the foolishness that we see, but 
lets try to be a little more civil when discussing technical matters.

   -- Bruce

More information about the lfs-support mailing list