Scenario #3: Penelope goes where the geeks are surfing.
The girl geek Melvin noticed over at the computer lab is named
Penelope. She's studying proteomics, and runs Linux on the laptop she
just bought because Linux supports the best software she can afford
for modeling protein folding.
Penelope is what the trade rags call a "power user". She's pretty
bright, and likes computers, but she's got more important things to
think about than the details of how to configure a kernel. Like
getting a better handle on the effect of van der Waals forces on alpha
sheets, or the latest paper on ribosomal electron transport, or why
she can't seem to meet men who don't bore the crap out of her even in
a fair-sized college town.
She's just heard about a PCMCIA card that has a MEMS array of chemical
sensors on it. The thing could replace the bulky, balky
gel-chromatography setup she's using now, and make it unnecessary for
her to fight other students for bench time. There's even a Linux
driver for the card (and user-space utilities to talk to it) on one of
the bio sites she uses -- way too specialized an item for her distro
to carry, and anyway she doesn't want to wait for the next release.
Penelope needs to build a kernel to support her exotic driver, but she
hasn't got more than the vaguest idea how to go about it. The
instructions with the driver source patch tell her to apply it at the
top level of a current Linux source tree and then just say "build the
kernel" before getting off into technicalia about the user-space
tools.
She could ask that guy who's been eyeing her over at the computer lab
for help; Penelope knows what a penguin T-shirt means, and he's not
too bad-looking, if a bit on the skinny side. On the other hand, she
knows that guys like that tend to take over the whole process when
they're trying to be helpful; they can't help displaying their prowess
and doing more than you asked for, it's biologically wired in. And
she's learned that letting someone else take over maintaining your
equipment properly in a way you don't understand is a good way to have
it flake out on you just short of a deadline.
On the third hand, she really *doesn't* want to spend her think time
absorbing a bunch of irrelevant hardware details just to get the one
driver she needs up and running. What she needs is some fast,
hassle-free technological empowerment, not Yet Another Learning
Experience. (And a boyfriend would be nice too, while she's wishing.)
If Penelope learns from the README file that all *she* has to do is
type "configure; make" to build a kernel that supports her hardware,
she can apply that MEMS card patch and build with confidence that the
effort is unlikely to turn into an infinite time sink.
Autoconfigure saves the day again. That guy in the penguin T-shirt
might even be impressed...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Guard with jealous attention the public liberty. Suspect every one
who approaches that jewel. Unfortunately, nothing will preserve it
but downright force. Whenever you give up that force, you are
inevitably ruined." -- Patrick Henry, speech of June 5 1788
"Eric S. Raymond" wrote:
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
Very few hardware vendors give out kernel patches... if any. The end
user method of choice I've seen is a tarball with files to build, or a
single .c file to build. Kernel autoconfiguration for vendor drivers
rarely comes into play, because the driver is built against the "current
kernel" headers, but not with the standard kernel build system and
tools.
Oh, and is Penelope single?
Jeff
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
"Eric S. Raymond" wrote:
>
> Scenario #3: Penelope goes where the geeks are surfing.
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
>
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
Is anyone arguing that autoconfig is *unconditionally bad*?
As long as it doesn't impact the ability to continue setting things manually, I
don't see how it could be bad.
For instances where you're building a new kernel on the system it's going to run
on, and you want all the devices, then use autoconfig. For anything else,
either start from scratch as usual or use autoconfig as a base to start from.
As long as we still have manual control if we want it, I don't see any problems.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Scenario #3: Penelope goes where the geeks are surfing.
>
> The girl geek Melvin noticed over at the computer lab is named
> Penelope. She's studying proteomics, and runs Linux on the laptop she
> just bought because Linux supports the best software she can afford
> for modeling protein folding.
>
> Penelope is what the trade rags call a "power user". She's pretty
> bright, and likes computers, but she's got more important things to
> think about than the details of how to configure a kernel. Like
> getting a better handle on the effect of van der Waals forces on alpha
> sheets, or the latest paper on ribosomal electron transport, or why
> she can't seem to meet men who don't bore the crap out of her even in
> a fair-sized college town.
>
> She's just heard about a PCMCIA card that has a MEMS array of chemical
> sensors on it. The thing could replace the bulky, balky
> gel-chromatography setup she's using now, and make it unnecessary for
> her to fight other students for bench time. There's even a Linux
> driver for the card (and user-space utilities to talk to it) on one of
> the bio sites she uses -- way too specialized an item for her distro
> to carry, and anyway she doesn't want to wait for the next release.
>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
>
> She could ask that guy who's been eyeing her over at the computer lab
> for help; Penelope knows what a penguin T-shirt means, and he's not
> too bad-looking, if a bit on the skinny side. On the other hand, she
> knows that guys like that tend to take over the whole process when
> they're trying to be helpful; they can't help displaying their prowess
> and doing more than you asked for, it's biologically wired in. And
> she's learned that letting someone else take over maintaining your
> equipment properly in a way you don't understand is a good way to have
> it flake out on you just short of a deadline.
>
> On the third hand, she really *doesn't* want to spend her think time
> absorbing a bunch of irrelevant hardware details just to get the one
> driver she needs up and running. What she needs is some fast,
> hassle-free technological empowerment, not Yet Another Learning
> Experience. (And a boyfriend would be nice too, while she's wishing.)
>
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
>
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
With todays lack of hooking methods you do want to give up even this one ?!
Damn you ... :-)
- Davide
On 2002-01-14T16:59:09,
"Eric S. Raymond" <[email protected]> said:
Eric, your talent as a standup comedian is certainly appreciated, as is all
the great work you do.
Could you please do it somewhere else but l-k until the drugs wear off?
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
> Scenario #3: Penelope goes where the geeks are surfing.
Dude, please go fix the *design* bugs in fetchmail before hounding
linux-kernel with additional flame wars.
-ben
On Mon, 14 Jan 2002 16:59:09 -0500
"Eric S. Raymond" <[email protected]> wrote:
> Scenario #3: Penelope goes where the geeks are surfing.
>
[SNIP]
>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
>
[SNIP]
So, she calls up one of the innumerable independent Linux support companies in
her area (hey, this is a fantasy scenario, right?) and tells them what she
needs, pays them $30, and guess what? she never needed to run anything
herself.
I think some people are getting too involved with the issue to see that SOME
people probably don't care what kernel they're running, or even what a kernel
is, they just want to give someone money to fix their problem. It's like your
local auto-repair shop - someone who knows about car engines wouldn't take
their car there except for major repairs, because they know what to do in most
situations, but most people just want to drive. If they ever get sick of
paying to put the mechanic's kids through college, they will learn how to
change the oil themselves, but honestly, most people simply can't be bothered.
And before you say that Linux is supposed to empower the people of the world,
not limit them, I wouldn't say that learning how to change my oil "empowers"
me all that much.
Eric S. Raymond writes:
> Scenario #3: Penelope goes where the geeks are surfing.
[...]
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
You know, I'm not really interested in whether Melvin or Penelope get
a root or not, and it's never occurred to me that kernel design should
be based on that.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Benjamin LaHaise <[email protected]>:
> On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
> > Scenario #3: Penelope goes where the geeks are surfing.
>
> Dude, please go fix the *design* bugs in fetchmail before hounding
> linux-kernel with additional flame wars.
Point out one and I'll fix it. I'm not satisfied that you have
understood what fetchmail is doing yet.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The common argument that crime is caused by poverty is a kind of
slander on the poor.
-- H. L. Mencken
On Mon, Jan 14, 2002 at 05:38:54PM -0500, Eric S. Raymond wrote:
> Point out one and I'll fix it. I'm not satisfied that you have
> understood what fetchmail is doing yet.
Really? Why am I the one receiving bounces from FETCHMAIL-DAEMON
when subscribers to mailing lists misconfigure their boxes? I am
completely unable to fix the problem, or even notify the user that
they are *losing* mail due to the broken design you came up with.
Meanwhile, I see you involved in lots of pointless threads on l-k
without understanding the typical usage patterns of kernels and
how distros actually support them.
-ben
--
Fish.
Richard Gooch <[email protected]>:
> You know, I'm not really interested in whether Melvin or Penelope get
> a root or not, and it's never occurred to me that kernel design should
> be based on that.
The phrase "get a root" is entertainingly ambiguous in this context, is it not?
Storytelling is the most effective form of exposition. It's a way to pull
technical issues out of the realm of abstraction, and help designers
realize that there are (at least potentially) real people involved.
I recommend it. Not just for communicating with others, but for your
own thought experiments in design.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Let us hope our weapons are never needed --but do not forget what
the common people knew when they demanded the Bill of Rights: An
armed citizenry is the first defense, the best defense, and the
final defense against tyranny.
If guns are outlawed, only the government will have guns. Only
the police, the secret police, the military, the hired servants of
our rulers. Only the government -- and a few outlaws. I intend to
be among the outlaws.
-- Edward Abbey, "Abbey's Road", 1979
<What's up with all the bad biology on linux-kernel? First there was the
never-ending "I don't know anything about evolution but I'll talk about how
it applies to software development anyway" thread, and now this horrible
mish-mash of half-correct terminology...>
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
I've shared a lab bench with Penelope. If she's at a school where she can
study proteomics and where she can get grant funding sufficient to buy a
"MEMS card," then all she has to do is talk to her departmental computer
support people. That's why they exist, and why distributions exist -- so
that Penelope does not have to deal with this horribly contrived scenario.
later,
chris
* Eric S. Raymond ([email protected]) wrote:
> Scenario #3: Penelope goes where the geeks are surfing.
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
>
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
$ apt-cache search kernel-patch | wc -l
66
And I guarantee that if Penelope calls up her vendor, she can get
someone to provide her a guaranteed-compatible and *tested* driver that
can be managed by her package manager for less than the price of the
pack of twelve she'll be using with the dude in the penguin t-shirt.
Please try to understand the entire _point_ of distributions and get a
grasp of how vendors work with the kernel, and stop waxing lyrical about
contrived situations.
Tom.
--
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | [email protected] |
^^-^^ `-------------------------------------------------------'
Eric S. Raymond writes:
> Richard Gooch <[email protected]>:
> > You know, I'm not really interested in whether Melvin or Penelope get
> > a root or not, and it's never occurred to me that kernel design should
> > be based on that.
>
> The phrase "get a root" is entertainingly ambiguous in this context,
> is it not?
Not to an Australian. It's quite unambiguous :->
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Benjamin LaHaise <[email protected]>:
> On Mon, Jan 14, 2002 at 05:38:54PM -0500, Eric S. Raymond wrote:
> > Point out one and I'll fix it. I'm not satisfied that you have
> > understood what fetchmail is doing yet.
>
> Really? Why am I the one receiving bounces from FETCHMAIL-DAEMON
> when subscribers to mailing lists misconfigure their boxes?
Because fetchmail is doing the same thing any other MTA would do in that
situation -- throwing up its hands, because it doesn't have and can't get
the information to compensate for the misconfiguration.
If you have some magic patch to fix this, I'll take it. If you have
nothing constructive to contribute, please take your venom elsewhere.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
He who joyfully marches to music in rank and file has already earned my
contempt. He has been given a large brain by mistake, since for him the
spinal cord would fully suffice.
-- Albert Einstein
On Mon, Jan 14, 2002 at 06:05:22PM -0500, Eric S. Raymond wrote:
> Because fetchmail is doing the same thing any other MTA would do in that
> situation -- throwing up its hands, because it doesn't have and can't get
> the information to compensate for the misconfiguration.
Nice cop out. Fetchmail is a hybrid MTA+MUA. Since it straddles the
line, it should follow the rules of least surprise, namely:
1. don't delete a messages without knowing they can be / are
delivered successfully
2. make sure error messages that come from temporary config
issues are sent to the person who can fix them.
FYI, it's easy to fix, just use the correct ordering of download, transmit,
delete that sendmail and other MTAs use. Sendmail doesn't delete a message
out of its spool just because it was sent to the next MTA in the chain,
instead it *waits* for the next MTA to acknowledge the successful receipt
of the message. Funnily, it even fsync()s the spool before acknowledging
incoming messages.
> If you have some magic patch to fix this, I'll take it. If you have
> nothing constructive to contribute, please take your venom elsewhere.
Eric, you're asking kernel developers to trust that you are dealing with
the design issues correctly. Part of that means understanding where the
priorities of the issues that concern you fit in with the rest of the
project. That means understanding what current practice is, and what it
will be to all the players involved (core kernel developers, bleeding edge
users, end users who want a stable system, distro users, distro developers).
So far, I see proof that you are not good at understanding design issues
that don't interest you. This flame war is proof that you're very out of
sync with the rest of the developers. I'm asking you to show some goodwill
by going back and fixing the design issues in your own project in order
to better understand some of the currents at work. Until then, I won't
use fetchmail, and I pity the poor users that do.
-ben
[email protected] wrote:
>
> In a message dated 1/14/2002 5:32:46 PM Eastern Standard Time,
> [email protected] writes:
>
> > "Eric S. Raymond" wrote:
> > > Penelope needs to build a kernel to support her exotic driver, but
> > she
> > > hasn't got more than the vaguest idea how to go about it. The
> > > instructions with the driver source patch tell her to apply it at
> > the
> > > top level of a current Linux source tree and then just say "build
> > the
> > > kernel" before getting off into technicalia about the user-space
> > > tools.
> >
> > Very few hardware vendors give out kernel patches... if any. The
> > end
> > user method of choice I've seen is a tarball with files to build, or
> > a
> > single .c file to build. Kernel autoconfiguration for vendor
> > drivers
> > rarely comes into play, because the driver is built against the
> > "current
> > kernel" headers, but not with the standard kernel build system and
> > tools.
> >
>
> When I provide drivers to hardware vendors (not many Linux so far,
> I have been working mostly in the Solaris and previously the Netware
> markets), I have built them with the standard kernel build system
> and tools. Now the vendors may actually provide these drivers as
> you describe, but if there were reason, they could certainly supply
> them as patches.
Yes, but no one does so because patches break all the time. C modules
built carefully for kernel compatibility are far more resistant to
change. People are more likely to ship -binary- modules than patches.
In sum, Eric's example is unrealistic.
Jeff
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
<snip of over-many-people's-heads description of advanced biology stuff>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
>
> She could ask that guy who's been eyeing her over at the computer lab
> for help; Penelope knows what a penguin T-shirt means, and he's not
> too bad-looking, if a bit on the skinny side. On the other hand, she
> knows that guys like that tend to take over the whole process when
> they're trying to be helpful; they can't help displaying their prowess
> and doing more than you asked for, it's biologically wired in. And
> she's learned that letting someone else take over maintaining your
> equipment properly in a way you don't understand is a good way to have
> it flake out on you just short of a deadline.
>
> On the third hand, she really *doesn't* want to spend her think time
> absorbing a bunch of irrelevant hardware details just to get the one
> driver she needs up and running. What she needs is some fast,
> hassle-free technological empowerment, not Yet Another Learning
> Experience. (And a boyfriend would be nice too, while she's wishing.)
So can we assume that our dear sweet Penelope has spent a bit of time
reading l-k and finding out about <insert your favorite brown-paper-bag
release here>? We wouldn't want her to destroy her newly-created data.
Also, since she has a laptop (which comes with all that finicky laptop
hardware), does the release of the kernel she grabbed have that nasty
tweak that fries the board in her laptop? (I've heard some rather nasty
horror stories, that's why I ask)
She can't very well patch her vendor kernel, because I sincerely doubt
the patch will apply cleanly, if this driver is such that it needs a
patch as opposed to just a module.
Also, what do we tell Penelope when her other piece of exotic hardware
that *was* supported in the vendor kernel, but isn't supported in the
vanilla kernel, stops working. Suddenly she can do her advanced biology
stuff, but can't print, or dial up w/ her winmodem, or whatever.
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
>
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
If Penelope is even a remote candidate for this scenario, I think
penguin-boy is already impressed ;-)
--
Nathan Walp || [email protected]
GPG Fingerprint: || http://faceprint.com/
5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E
On Mon, 2002-01-14 at 14:37, Bruce Harada wrote:
> And before you say that Linux is supposed to empower the people of the world,
> not limit them, I wouldn't say that learning how to change my oil "empowers"
> me all that much.
You should read "Zen and the Art of Motorcycle Maintenance"
Notwithstanding the book being a great read, it is very relevant to this
whole discussion.
-tduffy
--
He who receives an idea from me, receives instruction himself without
lessening mine; as he who lights his taper at mine, receives light
without darkening me. -- Thomas Jefferson
On Mon, Jan 14, 2002 at 07:50:53PM -0500, Nathan Walp wrote:
> She can't very well patch her vendor kernel, because I sincerely doubt
> the patch will apply cleanly, if this driver is such that it needs a
> patch as opposed to just a module.
If it needs a patch, it's messing with kernel internals and she certainly shouldn't
be trying it without an awareness of the potential interactions, or a "recommended
version" from the patch vendor. So if she needs a really stable configuration,
she needs to punt the problem to departmental support.
If it doesn't need a patch, the sensible and proper solution is to autoconfize the
external module source tree, which can adapt itself to different kernels correctly.
autoconfigure of kernel will definitely be useful to e.g. the users we see in
#kernelnewbies, but it is /not/ the right solution for Tilly, Penelope, Dick Dastardly
or any other of the Wacky Races crew Eric is talking about.
regards
john
--
"Now why did you have to go and mess up the child's head, so you can get another gold waterbed ?
You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ..."
On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
[snip]
> She's just heard about a PCMCIA card that has a MEMS array of chemical
> sensors on it. The thing could replace the bulky, balky
> gel-chromatography setup she's using now, and make it unnecessary for
> her to fight other students for bench time. There's even a Linux
> driver for the card (and user-space utilities to talk to it) on one of
> the bio sites she uses -- way too specialized an item for her distro
> to carry, and anyway she doesn't want to wait for the next release.
>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
[snip]
Wrong. She needs to compile a new module for her kernel. What might be
useful is some automagic tool that will find the vendor-provided kernel
source tree and config (which is usually /boot/config-`uname -r`, but
still findable anyhow) and then compile said module for her, toss it
into the modules dir and maybe even add it to the always-loaded module
list (just incase hotplug doesn't grok it).
With some support from people writing external drivers, you could even
have a file that lists things like which files are needed, a URL and
version info, and store it someplace too.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Benjamin LaHaise <[email protected]>:
> FYI, it's easy to fix, just use the correct ordering of download, transmit,
> delete that sendmail and other MTAs use.
I don't understand what you think you're seeing, but I am sure of
this; if I had been enough of a drug-addled lunatic to allow fetchmail
to delete mail before getting a positive acknowledge from the
downstream MTA, someone in the pool of over two thousand people who have sent
me bug reports and patches would have called me on it some time in the
six years of production use well before *you* entered the picture.
It's likely you're being hosed by an MTA that's sending back bogus 2xx
responses. That's happend before. Fetchmail can't magically cope
with MTAs that tell it lies.
Fetchmail *already works the way you recommend* -- as any idiot can
verify by reading the short section of the main driver loop where
dispatch and delete takes place. That's been an invariant of the code
since day one, and you thus clearly have no bloody idea what you are
flaming about.
Don't take my word for it. Go read the code. Until you've done so,
I suggest you take it off-list before you embarrass yourself further.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
A man who has nothing which he is willing to fight for, nothing
which he cares about more than he does about his personal safety,
is a miserable creature who has no chance of being free, unless made
and kept so by the exertions of better men than himself.
-- John Stuart Mill, writing on the U.S. Civil War in 1862
On Mon, Jan 14, 2002 at 06:39:54PM -0700, Tom Rini wrote:
> Wrong. She needs to compile a new module for her kernel. What might be
> useful is some automagic tool that will find the vendor-provided kernel
> source tree and config (which is usually /boot/config-`uname -r`, but
> still findable anyhow)
autoconf code already exists for this, it's a non-problem. Note they must use
the config in the header file of the vendor-provided kernel source tree, not
/boot/config-`uname -r`
There are two cases:
1) the vendor source tree is installed and set up with the right config -> use header file
2) it's installed and the config has changed. -> use header file
I don't see a point in ever looking at /boot/config-`uname -r` instead of
the source tree, given that we must compile against a tree configured like the
eventual running kernel anyway.
regards
john
--
"Now why did you have to go and mess up the child's head, so you can get another gold waterbed ?
You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ..."
On Mon, Jan 14, 2002 at 08:53:07PM -0500, Eric S. Raymond wrote:
> I don't understand what you think you're seeing, but I am sure of
> this; if I had been enough of a drug-addled lunatic to allow fetchmail
> to delete mail before getting a positive acknowledge from the
> downstream MTA, someone in the pool of over two thousand people who have sent
> me bug reports and patches would have called me on it some time in the
> six years of production use well before *you* entered the picture.
Uhm, as someone who has run a number of mailing lists for the past 6
years, I've seen fetchmail induced bounces numerous times, and 99% of
the time they're because the damn thing should default to a
--never-send-bounces-to-anyone.
> It's likely you're being hosed by an MTA that's sending back bogus 2xx
> responses. That's happend before. Fetchmail can't magically cope
> with MTAs that tell it lies.
That's part of what you have to deal with by being a hybrid MTA/MUA:
your error handling must be directed at the user of fetchmail, not the
originator of the message. The originator of the message has no control
over the misdelivery of the message due to user config file error, so
why should they receive the error? Bounces like these are very
difficult to determine what the address causing trouble is because of
the fact that fetchmail *is* an MUA -> it should not behave as if it is
purely an MTA.
> Fetchmail *already works the way you recommend* -- as any idiot can
> verify by reading the short section of the main driver loop where
> dispatch and delete takes place. That's been an invariant of the code
> since day one, and you thus clearly have no bloody idea what you are
> flaming about.
Good, at least that part of my understanding of it was wrong, and I'm
glad to hear that. But the behaviour is still indistinguishable from
the gross misdesign that it feels like. Namely, ask yourself why it
loses mail if the user makes a typo in the config file on their first
try? Who gets the bounce? Why should the message be deleted instead
of merely deferred?
Besides, I think you're trying to solve the wrong problem. A good many
readers of linux-kernel don't want to start seeing posts from Aunt Tillie
and would rather leave this ease of use issue to the distributions that
already make it easy as pie.
-ben
On Tue, Jan 15, 2002 at 02:07:58AM +0000, John Levon wrote:
> On Mon, Jan 14, 2002 at 06:39:54PM -0700, Tom Rini wrote:
>
> > Wrong. She needs to compile a new module for her kernel. What might be
> > useful is some automagic tool that will find the vendor-provided kernel
> > source tree and config (which is usually /boot/config-`uname -r`, but
> > still findable anyhow)
>
> autoconf code already exists for this, it's a non-problem.
Er, why on earth is it 'autoconf' tho? This isn't something that's
necessaryily a CONFIG_xxx issue, it's a 'compile this for me' issue.
> Note they must use
> the config in the header file of the vendor-provided kernel source tree, not
> /boot/config-`uname -r`
And why wouldn't the two match? If you're running a vendor-provided
kernel, /boot/config-`uname -r` should be the config for the
vendor-provided kernel (and its source tree)...
> There are two cases:
>
> 1) the vendor source tree is installed and set up with the right config -> use header file
>
> 2) it's installed and the config has changed. -> use header file
2) should never happen. I'm not talking about a patch (like said what
i2c does traditionally), I'm talking about driver.[ch].
> I don't see a point in ever looking at /boot/config-`uname -r` instead of
> the source tree, given that we must compile against a tree configured like the
> eventual running kernel anyway.
Because they should be the same thing? And why do you mention 'eventual
running kernel'. There is a running kernel. Compile the module, load
the module, work. No reboot (or kernel recompile) needed.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
[email protected] said:
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
Bzzt. The PCMCIA card in question wasn't plugged in at the time so didn't
get enabled, and autoconfigure didn't realise that the software for it
actually needed CONFIG_NETLINK_DEV even though it wasn't in use at the time.
The sensible all-modules-under-the-sun vendor kernel had netlink_dev
available though, just in case. But when she calls the support person who's
responsible for the pre-installed Linux on her workstation and she
admits that she compiled her own kernel, she gets told to go away.
Pity the people who wrote the driver didn't use the saner approach:
make -C /lib/modules/`uname -r`/kernel SUBDIRS=`pwd` modules
--
dwmw2
On Mon, 14 Jan 2002, Benjamin LaHaise wrote:
> On Mon, Jan 14, 2002 at 08:53:07PM -0500, Eric S. Raymond wrote:
> > I don't understand what you think you're seeing, but I am sure of
> > this; if I had been enough of a drug-addled lunatic to allow fetchmail
> > to delete mail before getting a positive acknowledge from the
> > downstream MTA, someone in the pool of over two thousand people who have sent
> > me bug reports and patches would have called me on it some time in the
> > six years of production use well before *you* entered the picture.
>
> Uhm, as someone who has run a number of mailing lists for the past 6
> years, I've seen fetchmail induced bounces numerous times, and 99% of
> the time they're because the damn thing should default to a
> --never-send-bounces-to-anyone.
It doesn't matter if people hose their qmail forwards without fetchmail
anywhere, a provider fails to provide envelope information for that dung
of pile that a multidrop POP3 mailbox is, somehow you can always screw
up mailing lists. Use VERP to figure who is bouncing on you. And now
please take this off-list.
> That's part of what you have to deal with by being a hybrid MTA/MUA:
> your error handling must be directed at the user of fetchmail, not the
> originator of the message. The originator of the message has no control
You have absolutely no clue of fetchmail. Get lost. Please. Come back
only after you got the *complete* fetchmail picture.
fetchmail does not bounce on its own for single-drop mailboxes, and as
long as 4.x.y or 5.3.x versions are still around on distributions, ESR
cannot do much about solutions you require either because users won't
get hold of the policy changes.
> the fact that fetchmail *is* an MUA -> it should not behave as if it is
> purely an MTA.
Fetchmail is by no means a MUA.
> Besides, I think you're trying to solve the wrong problem. A good many
> readers of linux-kernel don't want to start seeing posts from Aunt Tillie
> and would rather leave this ease of use issue to the distributions that
> already make it easy as pie.
Having a common solution upstream is the way to save duplicate efforts.
And now let the fetchmail part of this thread please die.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
"Eric S. Raymond" wrote:
> Richard Gooch <[email protected]>:
> > You know, I'm not really interested in whether Melvin or Penelope get
> > a root or not, and it's never occurred to me that kernel design should
> > be based on that.
>
> The phrase "get a root" is entertainingly ambiguous in this context, is it not?
>
> Storytelling is the most effective form of exposition.
Yes, if you mean "to confuse people" ;-)
> It's a way to pull
> technical issues out of the realm of abstraction,
Or get really out of topic. Be careful with your examples, sometimes they have
small errors here and there and the result, even when looks coherent, is invalid.
> and help designers
> realize that there are (at least potentially) real people involved.
Eric, if you want to create a tool that looks for the installed hardware/vendor
configuratio/etc. and from all of this information creates a configure file in the
Linux source tree go ahead. I don't think anybody will stop you if that's a
separated tool and not part of the Linux source tree.
Lets use an example, looks like you really like examples:
1) You create a project called "Linux autoconf".
2) You make it available as a tarball.
3) Some user that likes it downloads and installs the Linux kernel sources.
4) Same user downloads your "nice" tool and also installs it.
5) This user instead of using the traditional configuration methods just runs your
tool and gets all solved .... or all fkd up ;-)
I don't think anybody will stop you from doing such a tool, in fact nobody can,
but you'll need to look for help in other list ;-))
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: [email protected] [email protected]
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
On Tue, Jan 15, 2002 at 01:28:58PM +0000, David Woodhouse wrote:
> Pity the people who wrote the driver didn't use the saner approach:
> make -C /lib/modules/`uname -r`/kernel SUBDIRS=`pwd` modules
Which works quite pretty with 2.2.x Makefiles and Rules.make, but
does not work with 2.4.x. I don't know if this is intentional or
just oversight.
If someone has a working makefile using this saner approach and
even support subdirs I would apreciate it[1].
Thanks & Regards
Ingo Oeser
[1] and spend him a sixpack when I meet him next time ;-)
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
>>> 4. Chemnitzer Linux-Tag - 09.+10. Maerz 2002 <<<
http://www.tu-chemnitz.de/linux/tag/
[email protected] said:
> make -C /lib/modules/`uname -r`/kernel SUBDIRS=`pwd` modules
> Which works quite pretty with 2.2.x Makefiles and Rules.make, but does
> not work with 2.4.x. I don't know if this is intentional or just
> oversight.
> If someone has a working makefile using this saner approach and even
> support subdirs I would apreciate it[1].
It works for me with 2.4, and I use it all the time. See the GNUmakefiles in
MTD CVS which do it automatically for you if you're not already running as
part of a kernel build.
--
dwmw2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have watched this thread, and I am unable to understand what problems
people have with a autoconfigurator!
Eric, go ahead and produce an autoconfigurator. If it works, it will become a
useful tool for those who need it. It will not interfere with the current
practice of manual kernel configuration and will not cause any inconvenience
to developers. And it will be useful!
Think of it in the context of a magic "Build-me-an-optimised-kernel" button
which would appear on the desktop of distro X. Which could be useful.
The point is, people who have no need for an autoconfig tool need not use it.
Melvin configures manually.
Aunt Tillie uses her distro kernels.
The small group of people who have the knowledge/requirement to build their
own kernels, but without sufficent technical knowhow to configure it, and
understand some myriad options, will find the autoconfig tool useful. And
Linux is about covering all the groups, is it not?
Just my 0.02 euro.
*MatthewM*
- --
Paranoia is heightened awareness.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8RJhcoVQMDIAmueURAiMEAKCOP6jgj9/6LEhdXY9X2hnpNAslWQCeIwV6
K86eai2Nl5xtmuu92NbRbZA=
=JV5M
-----END PGP SIGNATURE-----
"Eric S. Raymond" <[email protected]> writes:
> Benjamin LaHaise <[email protected]>:
> > FYI, it's easy to fix, just use the correct ordering of download, transmit,
> > delete that sendmail and other MTAs use.
>
> I don't understand what you think you're seeing, but I am sure of
> this; if I had been enough of a drug-addled lunatic to allow fetchmail
> to delete mail before getting a positive acknowledge from the
> downstream MTA, someone in the pool of over two thousand people who have sent
> me bug reports and patches would have called me on it some time in the
> six years of production use well before *you* entered the picture.
>
> It's likely you're being hosed by an MTA that's sending back bogus 2xx
> responses. That's happend before. Fetchmail can't magically cope
> with MTAs that tell it lies.
>
> Fetchmail *already works the way you recommend* -- as any idiot can
> verify by reading the short section of the main driver loop where
> dispatch and delete takes place. That's been an invariant of the code
> since day one, and you thus clearly have no bloody idea what you are
> flaming about.
I'll bite, as I've been forced to use it at times.
1. User configures fetchmail to download from imap/pop3 account (with
the messages kept on the server and just recorded -- Ie. nothing is
deleted server side).
2. User has exim as local transport, and also gets normal SMTP
traffic.
3. User enables sender_verify, sender_verify_hosts_callback and
sender_verify_callback_domains which catches loads of spam and is
happy.
Then...
. User runs fetchmail
. fetchmail feeds email to exim
. exim does callback verification, and refuses email.
. fetchmail pretends it has delivered email, so _even if_ you hack your
MTA to say don't verify from localhost lost emails will never be
delivered by fetchmail (even though they are still on the server,
and fetchmail knew they didn't get sent).
...and that assumes that you swallow the argument that you should have
to reconfigure your MTA to work around fetchmail bugs.
--
James Antill -- [email protected]
The Hurd itself is aggressively multi-threaded and all of the locking has
been done with an eye towards multi-processor systems. That said, we have
not yet used a microkernel that stably supports multiple cpus.
James Antill <[email protected]>:
> . User runs fetchmail
> . fetchmail feeds email to exim
> . exim does callback verification, and refuses email.
> . fetchmail pretends it has delivered email, so _even if_ you hack your
> MTA to say don't verify from localhost lost emails will never be
> delivered by fetchmail (even though they are still on the server,
> and fetchmail knew they didn't get sent).
If you tell fetchmail's config about exim's antispam responses
correctly, this should not happen.
I have a lot of happy exim users on my development list. Perhaps
you should try asking questions there?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.
Please leave this discussion about fetchmail out of the list....
On 15 Jan 2002, James Antill wrote:
> "Eric S. Raymond" <[email protected]> writes:
>
> > Benjamin LaHaise <[email protected]>:
> > > FYI, it's easy to fix, just use the correct ordering of download,
> transmit,
> > > delete that sendmail and other MTAs use.
> >
> > I don't understand what you think you're seeing, but I am sure of
> > this; if I had been enough of a drug-addled lunatic to allow fetchmail
> > to delete mail before getting a positive acknowledge from the
> > downstream MTA, someone in the pool of over two thousand people who
> have sent
> > me bug reports and patches would have called me on it some time in the
> > six years of production use well before *you* entered the picture.
> >
> > It's likely you're being hosed by an MTA that's sending back bogus 2xx
> > responses. That's happend before. Fetchmail can't magically cope
> > with MTAs that tell it lies.
> >
> > Fetchmail *already works the way you recommend* -- as any idiot can
> > verify by reading the short section of the main driver loop where
> > dispatch and delete takes place. That's been an invariant of the code
> > since day one, and you thus clearly have no bloody idea what you are
> > flaming about.
>
> I'll bite, as I've been forced to use it at times.
>
> 1. User configures fetchmail to download from imap/pop3 account (with
> the messages kept on the server and just recorded -- Ie. nothing is
> deleted server side).
>
> 2. User has exim as local transport, and also gets normal SMTP
> traffic.
>
> 3. User enables sender_verify, sender_verify_hosts_callback and
> sender_verify_callback_domains which catches loads of spam and is
> happy.
>
> Then...
>
> .. User runs fetchmail
> .. fetchmail feeds email to exim
> .. exim does callback verification, and refuses email.
> .. fetchmail pretends it has delivered email, so _even if_ you hack your
> MTA to say don't verify from localhost lost emails will never be
> delivered by fetchmail (even though they are still on the server,
> and fetchmail knew they didn't get sent).
>
> ....and that assumes that you swallow the argument that you should have
> to reconfigure your MTA to work around fetchmail bugs.
>
> --
> James Antill -- [email protected]
> The Hurd itself is aggressively multi-threaded and all of the locking has
> been done with an eye towards multi-processor systems. That said, we have
> not yet used a microkernel that stably supports multiple cpus.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> If you tell fetchmail's config about exim's antispam responses
> correctly, this should not happen.
>
> I have a lot of happy exim users on my development list. Perhaps
> you should try asking questions there?
Aunt Tillie doesnt know what exim is
(ducks)
Alan
Thus spake Eric S. Raymond ([email protected]):
> Scenario #3: Penelope goes where the geeks are surfing.
Why are you posting all this crap to linux-kernel?
[58 lines that say "I want ./configure for the kernel" deleted]
Ever put a recent SuSE or RedHat CD in your computer?
Eric, there are hundreds of perfectly fine Linux problems you could
solve. Distributions will ship with generic kernels and lots of
modules. You are not supposed to patch the kernel unless you have some
minimal expertise. Requiring users to use Python will not help the
situation at all. Pardon the French, but don't you have any real
problems to solve?
You know, the kind of problem where solving it would actually help a few
people? Almost no standard user like Aunt Tilly or Penelope has a
reason to compile a kernel, ever. Rule 1 of computing: optimize the
_common_ case. This case is not common.
Felix
Agreed. ESR is reading too much of "Unix haters handbook" and should
take a pinch of reality.
p.
Bruce Harada([email protected])@Tue, Jan 15, 2002 at 07:37:49AM +0900:
> On Mon, 14 Jan 2002 16:59:09 -0500
> "Eric S. Raymond" <[email protected]> wrote:
>
> > Scenario #3: Penelope goes where the geeks are surfing.
> >
> [SNIP]
> >
> > Penelope needs to build a kernel to support her exotic driver, but she
> > hasn't got more than the vaguest idea how to go about it. The
> > instructions with the driver source patch tell her to apply it at the
> > top level of a current Linux source tree and then just say "build the
> > kernel" before getting off into technicalia about the user-space
> > tools.
> >
> [SNIP]
>
> So, she calls up one of the innumerable independent Linux support companies in
> her area (hey, this is a fantasy scenario, right?) and tells them what she
> needs, pays them $30, and guess what? she never needed to run anything
> herself.
>
> I think some people are getting too involved with the issue to see that SOME
> people probably don't care what kernel they're running, or even what a kernel
> is, they just want to give someone money to fix their problem. It's like your
> local auto-repair shop - someone who knows about car engines wouldn't take
> their car there except for major repairs, because they know what to do in most
> situations, but most people just want to drive. If they ever get sick of
> paying to put the mechanic's kids through college, they will learn how to
> change the oil themselves, but honestly, most people simply can't be bothered.
>
> And before you say that Linux is supposed to empower the people of the world,
> not limit them, I wouldn't say that learning how to change my oil "empowers"
> me all that much.
--
Create like God. Command like a King. Work like a Slave.
110461387
http://gpg.md5.ca
http://perlpimp.com