[lfs-support] Ethernet Card Not Found

akhiezer lfs65 at cruziero.com
Tue Nov 26 11:24:58 PST 2013


> 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.


>
> Simon.
>
> -- 
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
>


--



More information about the lfs-support mailing list