Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
James Bottomley :
> Actually, I think this whole code vs people debate is a straw man and
> inherently inimical to the discussion. In neither code of conduct (old
> or new) is there any statement that allows one to make a value judgment
> of people relative to code, so the very premise you're all arguing on
> doesn't exist.
The author's original version of the new CoC is, however, associated
with (and intended by its author to implement) "The Post-Meritocracy
Manifesto".
https://postmeritocracy.org/
Do you think it's a stretch to see "people > code" in that?
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
signature.asc
Description: PGP signature
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
James Bottomley :
> Actually, I think this whole code vs people debate is a straw man and
> inherently inimical to the discussion. In neither code of conduct (old
> or new) is there any statement that allows one to make a value judgment
> of people relative to code, so the very premise you're all arguing on
> doesn't exist.
The author's original version of the new CoC is, however, associated
with (and intended by its author to implement) "The Post-Meritocracy
Manifesto".
https://postmeritocracy.org/
Do you think it's a stretch to see "people > code" in that?
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
signature.asc
Description: PGP signature
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
Bruce Perens :
> The anonymous person is generally thought to have appeared on the net
> previously as MikeeUSA. That entity has a well-recorded history of misogyny
> and other anti-social behaviour. He's also complained to me recently that
> because of "people like me", the law prohibits him from marrying very young
> women. I mean single-digit young. Although he is not at all meritorious of
> your civil behavior, you may not wish to lower yourself to his level.
I strongly doubt it. I've had my own run-in with MikeeUSA; I remember
it vividly and unpleasantly. The prose style doesn't match. MikeeUSA
could barely maintain coherent communication; this guy is using
language that indicates he's at least several degrees brighter.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
Bruce Perens :
> The anonymous person is generally thought to have appeared on the net
> previously as MikeeUSA. That entity has a well-recorded history of misogyny
> and other anti-social behaviour. He's also complained to me recently that
> because of "people like me", the law prohibits him from marrying very young
> women. I mean single-digit young. Although he is not at all meritorious of
> your civil behavior, you may not wish to lower yourself to his level.
I strongly doubt it. I've had my own run-in with MikeeUSA; I remember
it vividly and unpleasantly. The prose style doesn't match. MikeeUSA
could barely maintain coherent communication; this guy is using
language that indicates he's at least several degrees brighter.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Eben Moglen : > reputational damage is *specifically* recognized as grounds for relief. > > No. Reputational damage is not mentioned at all, let alone > specifically recognized. I have no difficulty in finding the word "reputation" in the brief in in proximity with the phrase "increasing [the programmer's] recognition in his profession". In fact the brief notes " The Eleventh Circuit has recognized the economic motives inherent in public licenses, *even where profit is not immediate*" (Emphasis mine.) And "The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder *that the law will enforce.*" (Emphasis mine.) You seem to be denying that the brief says what it actually says. It not only qualifies reputational gain as a kind of economic gain - and thus losses as damage - but cites the Eleventh Circuit as a previous authority for the proposition, and affirms that these gains and losses can be a matter for the law. This disinclines me to trust the rest of your analysis or assertions. I think you are advocating for your interest in the perceived irrevocability of the GPL, and where this implies being less than fully forthcoming about the actual risks in *this* situation you are committing something perilously close to suppressio veri. This is not helpful. I've lived with a practising attorney since about the time she was one of the first-line legal reviewers for the original GPL back in the 1980s - we probably still have the draft printout with her scribbled annotations on it somewhere. "Only lawyers can interpret this voodoo" is not a good line to pull on me when it comes to open-source licensing; I don't buy it and she wouldn't either. Here's another sentence from the brief that I had forgotten: "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material." - a particularly telling sentence in regard to the current controversy, and one I had forgotten. That there could be enough to win the day for the license revokers - they don't actually have to revoke, just assert that control. Pretty much equivalent to what the the Berne Convention's moral-rights provision does in Europe - they could claim that the CoC is a defacement of their work to which they refuse assent and have a case. I am not at all doubtful that the dissidents know these things; some of the language in the broadsides to lkml so indicates. Which is why I'm trying to get the kernel leadership to repair its unnecessarily high-handed behavior before somebody gets pissed off enough to actually drop a bomb. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Eben Moglen : > reputational damage is *specifically* recognized as grounds for relief. > > No. Reputational damage is not mentioned at all, let alone > specifically recognized. I have no difficulty in finding the word "reputation" in the brief in in proximity with the phrase "increasing [the programmer's] recognition in his profession". In fact the brief notes " The Eleventh Circuit has recognized the economic motives inherent in public licenses, *even where profit is not immediate*" (Emphasis mine.) And "The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder *that the law will enforce.*" (Emphasis mine.) You seem to be denying that the brief says what it actually says. It not only qualifies reputational gain as a kind of economic gain - and thus losses as damage - but cites the Eleventh Circuit as a previous authority for the proposition, and affirms that these gains and losses can be a matter for the law. This disinclines me to trust the rest of your analysis or assertions. I think you are advocating for your interest in the perceived irrevocability of the GPL, and where this implies being less than fully forthcoming about the actual risks in *this* situation you are committing something perilously close to suppressio veri. This is not helpful. I've lived with a practising attorney since about the time she was one of the first-line legal reviewers for the original GPL back in the 1980s - we probably still have the draft printout with her scribbled annotations on it somewhere. "Only lawyers can interpret this voodoo" is not a good line to pull on me when it comes to open-source licensing; I don't buy it and she wouldn't either. Here's another sentence from the brief that I had forgotten: "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material." - a particularly telling sentence in regard to the current controversy, and one I had forgotten. That there could be enough to win the day for the license revokers - they don't actually have to revoke, just assert that control. Pretty much equivalent to what the the Berne Convention's moral-rights provision does in Europe - they could claim that the CoC is a defacement of their work to which they refuse assent and have a case. I am not at all doubtful that the dissidents know these things; some of the language in the broadsides to lkml so indicates. Which is why I'm trying to get the kernel leadership to repair its unnecessarily high-handed behavior before somebody gets pissed off enough to actually drop a bomb. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Al Viro : > * in case it needs to be spelled out: I am not at all interested > in that kind of stunts. One of the reasons I thoroughly despise RMS > and his bunch is the leverage game they tried to play with GPLv3; > damned if I'm going to lower myself to their level. Sorry, I did not mean to imply that you are one with the license-revokers. More like "if even Al Viro thinks you fucked up your process, it would be unwise to dismiss the opposition to the CoC as mere trolls". *I* can't dismiss it, because I read my mail. Apparently lots of people think that it is *my* job to fix this mess, or at least to give it a good hard try. I doubt they're trolling; what would be the point? -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Al Viro : > * in case it needs to be spelled out: I am not at all interested > in that kind of stunts. One of the reasons I thoroughly despise RMS > and his bunch is the leverage game they tried to play with GPLv3; > damned if I'm going to lower myself to their level. Sorry, I did not mean to imply that you are one with the license-revokers. More like "if even Al Viro thinks you fucked up your process, it would be unwise to dismiss the opposition to the CoC as mere trolls". *I* can't dismiss it, because I read my mail. Apparently lots of people think that it is *my* job to fix this mess, or at least to give it a good hard try. I doubt they're trolling; what would be the point? -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
NeilBrown :
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
You may be right that these are semi-distinct groups. I don't think
the distinction makes a lot of difference to my argument, though.
Either way, (a) there's been a process failure by the leadership, and
(b) the threat of a massive legal disruption is real.
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
I'm...not sure I do. I was going to agree with you that it's a
massive overreaction, but then a simple question occurred to me: what
else could *I* do if I thought I had a significant stake (I don't; my
kernel contributions are minor and old) and felt my interests were
damaged?
All this could have been avoided so easily. A felt need for a new Code
should not have been followed by the immediate imposition of one,
but by a public RFC process and consensus-building - a process in which
even those who lost arguments about the construction of the code could
know they had been heard.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
signature.asc
Description: PGP signature
Re: The linux devs can rescind their license grant.
NeilBrown :
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
You may be right that these are semi-distinct groups. I don't think
the distinction makes a lot of difference to my argument, though.
Either way, (a) there's been a process failure by the leadership, and
(b) the threat of a massive legal disruption is real.
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
I'm...not sure I do. I was going to agree with you that it's a
massive overreaction, but then a simple question occurred to me: what
else could *I* do if I thought I had a significant stake (I don't; my
kernel contributions are minor and old) and felt my interests were
damaged?
All this could have been avoided so easily. A felt need for a new Code
should not have been followed by the immediate imposition of one,
but by a public RFC process and consensus-building - a process in which
even those who lost arguments about the construction of the code could
know they had been heard.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
signature.asc
Description: PGP signature
Re: The linux devs can rescind their license grant.
Theodore Y. Ts'o : > On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > > GPLed software have a specific right to relief (including injunctive > > relief) against misappropriation of their software. That ruling (which > > was the case of first impression on the binding status of the GPL) > > reputational damage is *specifically* recognized as grounds for relief. > > I've read the legal briefs, and I'm pretty sure they don't say what > you are claiming they say. Yes, I'm not a lawyer --- but that's OK > --- neither are you. How much are you willing to gamble on not being wrong? > The *vast* majority of the "anti-CoC dissidents" who have been > advancing this argument, have, as near as I can tell, little or no > copyright ownership in the kernel. I do not have any facts with which to dispute this specific claim. However, I do notice that a significant number of long-time contributors have put themselves in the anti-CoC camp. I note Al Viro as a recent example. Even supposing you are right about most of the anti-Coc people being outsiders, a tiny minority of people with a genuine IP stake could do a lot of damage. I ask again: how much are you willing to gamble on not being wrong? I definitely do not want to see the kind of explosion we could witness. I think you are making it more likely rather than less by appearing high-handed and dismissive. Because, whatever the merits of the CoC itself, there has been a process failure here. It doesn't look good to be defending that failure. A change like the CoC adoption was not a good thing to do without proper public notice, discussion, and consensus-building *beforehand*. This was an unforced error on the part of the leadership group; please, *please* don't compound it by digging in around the error. Do you really think you're going to win hearts and minds among insider dissidents - people with a genuine stake - by dismissing the opposition as a troll job? Instead of declaiming about "trolls", how about we fix the process failure instead? -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Theodore Y. Ts'o : > On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > > GPLed software have a specific right to relief (including injunctive > > relief) against misappropriation of their software. That ruling (which > > was the case of first impression on the binding status of the GPL) > > reputational damage is *specifically* recognized as grounds for relief. > > I've read the legal briefs, and I'm pretty sure they don't say what > you are claiming they say. Yes, I'm not a lawyer --- but that's OK > --- neither are you. How much are you willing to gamble on not being wrong? > The *vast* majority of the "anti-CoC dissidents" who have been > advancing this argument, have, as near as I can tell, little or no > copyright ownership in the kernel. I do not have any facts with which to dispute this specific claim. However, I do notice that a significant number of long-time contributors have put themselves in the anti-CoC camp. I note Al Viro as a recent example. Even supposing you are right about most of the anti-Coc people being outsiders, a tiny minority of people with a genuine IP stake could do a lot of damage. I ask again: how much are you willing to gamble on not being wrong? I definitely do not want to see the kind of explosion we could witness. I think you are making it more likely rather than less by appearing high-handed and dismissive. Because, whatever the merits of the CoC itself, there has been a process failure here. It doesn't look good to be defending that failure. A change like the CoC adoption was not a good thing to do without proper public notice, discussion, and consensus-building *beforehand*. This was an unforced error on the part of the leadership group; please, *please* don't compound it by digging in around the error. Do you really think you're going to win hearts and minds among insider dissidents - people with a genuine stake - by dismissing the opposition as a troll job? Instead of declaiming about "trolls", how about we fix the process failure instead? -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Greg Kroah-Hartman : > On Thu, Oct 25, 2018 at 07:56:26AM +, visionsofal...@redchan.it wrote: > > The linux devs can rescind their license grant. > > No they can not, please do not keep spreading false information. I think the confusion about whether applying GPL can be rescinded has obscured the most serious actual threat vector. Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of GPLed software have a specific right to relief (including injunctive relief) against misappropriation of their software. That ruling (which was the case of first impression on the binding status of the GPL) reputational damage is *specifically* recognized as grounds for relief. The anti-CoC dissidents don't have to rescind their license grant to cause a great deal of trouble. Instead they can invoke the doctrine established in Jacobsen vs. Katzer, seeking restraining orders. The line of argument is so simple that I could probably brief it myself, and I'm not a lawyer - just somebody who had to become a topic expert in this area to do my job as the founding president of OSI. For that matter, I don't think the question of whether the GPL can be rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing attorney who has also studied the relevant law. Be very skeptical about what the FSF or SFC tells you about this; they have a very strong institutional/ideological incentive to affirm irrevocability regardless of what the law actually says. I, on the other hand, don't have an ideological stake to defend in that argument; I'm telling you that the doctrine forbidding perpetual grants may very well have teeth here. There is, at any rate, significant risk that a court will see it that way. Between Jacobsen vs. Katzer and the prohibition against perpetual grants I think you are incurring a grave risk by assuming the dissidents have no ammunition. Better for both sides to climb down from a confrontational position before real damage gets done. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Greg Kroah-Hartman : > On Thu, Oct 25, 2018 at 07:56:26AM +, visionsofal...@redchan.it wrote: > > The linux devs can rescind their license grant. > > No they can not, please do not keep spreading false information. I think the confusion about whether applying GPL can be rescinded has obscured the most serious actual threat vector. Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of GPLed software have a specific right to relief (including injunctive relief) against misappropriation of their software. That ruling (which was the case of first impression on the binding status of the GPL) reputational damage is *specifically* recognized as grounds for relief. The anti-CoC dissidents don't have to rescind their license grant to cause a great deal of trouble. Instead they can invoke the doctrine established in Jacobsen vs. Katzer, seeking restraining orders. The line of argument is so simple that I could probably brief it myself, and I'm not a lawyer - just somebody who had to become a topic expert in this area to do my job as the founding president of OSI. For that matter, I don't think the question of whether the GPL can be rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing attorney who has also studied the relevant law. Be very skeptical about what the FSF or SFC tells you about this; they have a very strong institutional/ideological incentive to affirm irrevocability regardless of what the law actually says. I, on the other hand, don't have an ideological stake to defend in that argument; I'm telling you that the doctrine forbidding perpetual grants may very well have teeth here. There is, at any rate, significant risk that a court will see it that way. Between Jacobsen vs. Katzer and the prohibition against perpetual grants I think you are incurring a grave risk by assuming the dissidents have no ammunition. Better for both sides to climb down from a confrontational position before real damage gets done. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Greg Kroah-Hartman : > This patch series adds this new document to the kernel tree, as well as > removes a paragraph from the existing Code of Conduct that was > bothersome to many maintainers. I think the changes have improved it. There is still a process issue with how this code was promulgated that is clearly bothering a lot of people, but I hope that problem is well enough understood that we don't need to rehash it. More transparency, more consultation, and more notice of intent to revise would help head off future problems. I do have one content recommendation. In the version at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst which I presume is current, I see a paragraph that reads as follows: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for everyone, regardless of age, >body >size, disability, ethnicity, sex characteristics, gender identity and >expression, level of experience, education, socio-economic status, nationality, >personal appearance, race, religion, or sexual identity and orientation. I recommend that all the text from "everyone" on be struck as (a) unnecessary, and (b) tending to embroil the project in politico-cultural wars that can do it no good - and replaced by "every individual". That is, the result would read: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for every individual. That is all that needs to be said. Listing all those specific categories of "regardless of" implicitly privileges certain kinds of identity (those listed) and disfavors others (those not listed). Further, some of the phrases used fo categories are political shibboleths that unavoidably drag in American presumptions not appropriate for an international project. Best to leave the whole mess out and just pledge to treat individuals well. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Greg Kroah-Hartman : > This patch series adds this new document to the kernel tree, as well as > removes a paragraph from the existing Code of Conduct that was > bothersome to many maintainers. I think the changes have improved it. There is still a process issue with how this code was promulgated that is clearly bothering a lot of people, but I hope that problem is well enough understood that we don't need to rehash it. More transparency, more consultation, and more notice of intent to revise would help head off future problems. I do have one content recommendation. In the version at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst which I presume is current, I see a paragraph that reads as follows: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for everyone, regardless of age, >body >size, disability, ethnicity, sex characteristics, gender identity and >expression, level of experience, education, socio-economic status, nationality, >personal appearance, race, religion, or sexual identity and orientation. I recommend that all the text from "everyone" on be struck as (a) unnecessary, and (b) tending to embroil the project in politico-cultural wars that can do it no good - and replaced by "every individual". That is, the result would read: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for every individual. That is all that needs to be said. Listing all those specific categories of "regardless of" implicitly privileges certain kinds of identity (those listed) and disfavors others (those not listed). Further, some of the phrases used fo categories are political shibboleths that unavoidably drag in American presumptions not appropriate for an international project. Best to leave the whole mess out and just pledge to treat individuals well. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Josh Triplett : > > The words removed by this patch are a political statement. > > Choosing not to say those words is a political statement. The situation is not symmetrical. Choosing the protected classes in the CoC is a *change* in its implied politics. It's a change that is, obviously from LKML traffic, very contentious. If this were a tpurely technical matter, it would be described as not backwards-compatible. It's a change that, I submit, should not have been made without a clear consensus *in favor* of the change. Our culture has a process for this. It's called RFCs. If we want to designate protected classes to be called out in conductt guidelines, an RFC should be floated first and the change should be made only if rough consensus has been achieved. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Josh Triplett : > > The words removed by this patch are a political statement. > > Choosing not to say those words is a political statement. The situation is not symmetrical. Choosing the protected classes in the CoC is a *change* in its implied politics. It's a change that is, obviously from LKML traffic, very contentious. If this were a tpurely technical matter, it would be described as not backwards-compatible. It's a change that, I submit, should not have been made without a clear consensus *in favor* of the change. Our culture has a process for this. It's called RFCs. If we want to designate protected classes to be called out in conductt guidelines, an RFC should be floated first and the change should be made only if rough consensus has been achieved. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
(I mistakenly sent this with 'r' previously. Please reply to this copy.)
Alan Cox :
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
(I mistakenly sent this with 'r' previously. Please reply to this copy.)
Alan Cox :
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Alan Cox :
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Alan Cox :
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Licenses and revocability, in a paragraph or less.
freedomfromr...@aaathats3as.com : > As has been stated in easily accessible terms elsewhere: > "Most courts hold that simple, non-exclusive licenses with unspecified > durations that are silent on revocability are revocable at will. This means > that the licensor may terminate the license at any time, with or without > cause." + Furthermore, license revocation is not the only option. In Jacobsen vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that open-source developers have an actionable right not to have their software misappropriated even though the resulting damages are only reputational rather than monetary. Under that theory, developers can seek an injunction against a misappropriating party without globally revoking their license. The application of that case law to this situation is left as an easy exercise for the reader. Any competent paralegal could write the brief in an evening. Hell, I could almost do it myself. I do not personally want to see this happen. But that it is possible is a fact all parties must deal with. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Licenses and revocability, in a paragraph or less.
freedomfromr...@aaathats3as.com : > As has been stated in easily accessible terms elsewhere: > "Most courts hold that simple, non-exclusive licenses with unspecified > durations that are silent on revocability are revocable at will. This means > that the licensor may terminate the license at any time, with or without > cause." + Furthermore, license revocation is not the only option. In Jacobsen vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that open-source developers have an actionable right not to have their software misappropriated even though the resulting damages are only reputational rather than monetary. Under that theory, developers can seek an injunction against a misappropriating party without globally revoking their license. The application of that case law to this situation is left as an easy exercise for the reader. Any competent paralegal could write the brief in an evening. Hell, I could almost do it myself. I do not personally want to see this happen. But that it is possible is a fact all parties must deal with. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Theodore Y. Ts'o :
> There have been those who have characterized the GPL as being more
> than just a license, but also a political statement. And yet, many
> projects, include Linus, use the GPL without necessarily subscribing
> to all of Richard Stallman's positions, political or otherwise.
The case isn't parallel. Every kernel dev knew they were joining a
commons defined by GPL terms when they signed on. Regulation of
soi-disant "hateful" speech and "diversity" objectives, on the other
hand, are a *new* set of claims and norms not entailed in established
practice.
There ought to be much broader consensus before anything like that is done -
and I would say that even about new political claims I myself supported.
Instead, what we have is open revolt from a dissident faction that thinks
the project would be better destroyed than under the CoC.
That should be a clue that imposing the CoC without a lot of public
discussion and preparation was a mistake, and it should be revereted until
at least rough consensus in fovor of some improvement on the old
Code is achieved.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Theodore Y. Ts'o :
> There have been those who have characterized the GPL as being more
> than just a license, but also a political statement. And yet, many
> projects, include Linus, use the GPL without necessarily subscribing
> to all of Richard Stallman's positions, political or otherwise.
The case isn't parallel. Every kernel dev knew they were joining a
commons defined by GPL terms when they signed on. Regulation of
soi-disant "hateful" speech and "diversity" objectives, on the other
hand, are a *new* set of claims and norms not entailed in established
practice.
There ought to be much broader consensus before anything like that is done -
and I would say that even about new political claims I myself supported.
Instead, what we have is open revolt from a dissident faction that thinks
the project would be better destroyed than under the CoC.
That should be a clue that imposing the CoC without a lot of public
discussion and preparation was a mistake, and it should be revereted until
at least rough consensus in fovor of some improvement on the old
Code is achieved.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Christoph Conrads : > The CoC is a political document: > https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432 And there is no level on which this is anything but bad. The kernel devs are a very large, very diverse, multi-national, multi-cultural group. We have nothing to gain by getting entangled with political culture wars, and everything to lose. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Christoph Conrads : > The CoC is a political document: > https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432 And there is no level on which this is anything but bad. The kernel devs are a very large, very diverse, multi-national, multi-cultural group. We have nothing to gain by getting entangled with political culture wars, and everything to lose. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
On holy wars, and a plea for peace
e margins of society; minority regious groups are the best-studied
case. The larger and more varied your group is, the more penalty there
is for trying to be too normative.
What we have now is a situation in which a subgroup within the Linux
kernel's subculture threatens destructive revolt because not only do
they think the slider been pushed too high in a normative direction,
but because they think the CoC is an attempt to change the group's
telos.
The first important thing to get is that this revolt is not really
about any of the surface issues the CoC was written to address. It
would be maximally unhelpful to accuse the anti-CoC people of being
pro-sexism, or anti-minority, or whatever. Doing that can only inflame
their sense that the group telos is being hijacked. They make it
clear; they signed on to participate in a meritocracy with reputation
rewards, and they think that is being taken way from them.
One way to process this complaint is to assert that the CoC's new
concerns are so important that the anti-CoC faction can be and
should be fought to the point where they withdraw or surrender.
The trouble with this way of responding is that it *is* in fact
a hijacking of the group's telos - an assertion that we ought to
have new terminal values replacing old ones that the objectors
think they're defending.
So a really major question here is: what is the telos of this
subculture? Does the new CoC express it? Have the objectors
expressed it?
The question *not* to get hung up on is what any individual's
choice in this matter says about their attitude towards, say,
historically underepresented minorities. It is perfectly
consistent to be pro-tolerance and pro-inclusion while
believing *this* subculture ought to be all about producing
good code without regard to who is offended by the process.
Not every kind of good work has to be done everywhere.
Nobody demands that social-justice causes demonstrate
their ability to write C.
That last paragraph may sound like I have strayed from neutrality into
making a value claim, but not really. It's just another way of saying
that different groups have different teloi, and different ethoi
proceeding from them. Generally speaking (that is, unless it commits
actual crimes) you can only judge a group by how it fulfills its own
telos, not those of others.
So we come back to two questions:
1. What is our telos?
2. Given our telos, do we have the most inclusive (least normative)
ethos possible to achieve it?
When you have an answer to that question, you will know what
we need to do about the CoC and the "killswitch" revolt.
--
http://www.catb.org/~esr/;>Eric S. Raymond
The spirit of resistance to government is so valuable on certain occasions,
that I wish it always to be kept alive. It will often be exercised when
wrong, but better so than not to be exercised at all. I like a little
rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787
On holy wars, and a plea for peace
e margins of society; minority regious groups are the best-studied
case. The larger and more varied your group is, the more penalty there
is for trying to be too normative.
What we have now is a situation in which a subgroup within the Linux
kernel's subculture threatens destructive revolt because not only do
they think the slider been pushed too high in a normative direction,
but because they think the CoC is an attempt to change the group's
telos.
The first important thing to get is that this revolt is not really
about any of the surface issues the CoC was written to address. It
would be maximally unhelpful to accuse the anti-CoC people of being
pro-sexism, or anti-minority, or whatever. Doing that can only inflame
their sense that the group telos is being hijacked. They make it
clear; they signed on to participate in a meritocracy with reputation
rewards, and they think that is being taken way from them.
One way to process this complaint is to assert that the CoC's new
concerns are so important that the anti-CoC faction can be and
should be fought to the point where they withdraw or surrender.
The trouble with this way of responding is that it *is* in fact
a hijacking of the group's telos - an assertion that we ought to
have new terminal values replacing old ones that the objectors
think they're defending.
So a really major question here is: what is the telos of this
subculture? Does the new CoC express it? Have the objectors
expressed it?
The question *not* to get hung up on is what any individual's
choice in this matter says about their attitude towards, say,
historically underepresented minorities. It is perfectly
consistent to be pro-tolerance and pro-inclusion while
believing *this* subculture ought to be all about producing
good code without regard to who is offended by the process.
Not every kind of good work has to be done everywhere.
Nobody demands that social-justice causes demonstrate
their ability to write C.
That last paragraph may sound like I have strayed from neutrality into
making a value claim, but not really. It's just another way of saying
that different groups have different teloi, and different ethoi
proceeding from them. Generally speaking (that is, unless it commits
actual crimes) you can only judge a group by how it fulfills its own
telos, not those of others.
So we come back to two questions:
1. What is our telos?
2. Given our telos, do we have the most inclusive (least normative)
ethos possible to achieve it?
When you have an answer to that question, you will know what
we need to do about the CoC and the "killswitch" revolt.
--
http://www.catb.org/~esr/;>Eric S. Raymond
The spirit of resistance to government is so valuable on certain occasions,
that I wish it always to be kept alive. It will often be exercised when
wrong, but better so than not to be exercised at all. I like a little
rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>: > Upon further investigation, it seems I was mistaken. I apologise for my tone. Accepted. I wish more people had the grace you do, to apologize when you know you've been mistaken or unfair; it would make this list a better place. > Momenco Ocelot boot flash device > CONFIG_MTD_OCELOT > This enables access routines for the boot flash device and for the > NVRAM on the Momenco Ocelot board. If you have one of these boards > and would like access to either of these, say 'Y'. Incorporated. I have also received mail from someone who can fill in the new MIPS entries, so initial results from the posting are quite good. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The direct use of physical force is so poor a solution to the problem of limited resources that it is commonly employed only by small children and great nations. -- David Friedman - 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/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
Steven J. Hill <[EMAIL PROTECTED]>: > I can fill in the blanks on all of these for you. I won't clutter > up the mailing list with the complete descriptions. That would be excellent. Please do! -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. I like a little rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787 - 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/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] said:
> > According to my cross-reference generator, the following symbols have
> > missing help in 2.4.6-pre9:
>
> Please fix your cross-reference generator as previously discussed before
> posting these lists again.
I put the symbols we discussed previously on my ignore list. What's
your beef this time?
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
The saddest life is that of a political aspirant under democracy. His
failure is ignominious and his success is disgraceful.
-- H.L. Mencken
-
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/
Cross-reference analysis reveals problems in 2.4.6pre9
According to my cross-reference generator, the following symbols have missing help in 2.4.6-pre9: CONFIG_AU1000_UART CONFIG_BLUEZ_L2CAP CONFIG_DDB5477 CONFIG_EVB_PCI1 CONFIG_FORWARD_KEYBOARD CONFIG_GDB_CONSOLE CONFIG_HD64465_IOBASE CONFIG_IT8172_REVC CONFIG_IT8172_SCR0 CONFIG_IT8172_SCR1 CONFIG_LL_DEBUG CONFIG_MAPLE CONFIG_MAPLE_KEYBOARD CONFIG_MAPLE_MOUSE CONFIG_MIDI_VIA82CXXX CONFIG_MIPS_EV64120 CONFIG_MIPS_EV96100 CONFIG_MIPS_ITE8172 CONFIG_MIPS_IVR CONFIG_MIPS_PB1000 CONFIG_MIPS_UNCACHED CONFIG_MTD_OCELOT CONFIG_NINO CONFIG_NINO_16MB CONFIG_NINO_4MB CONFIG_NINO_8MB CONFIG_ORION CONFIG_SH_7751_SOLUTION_ENGINE CONFIG_ST40_LMI_MEMORY CONFIG_SYSCLK_100 CONFIG_SYSCLK_75 CONFIG_SYSCLK_83 CONFIG_TULIP_MMIO This list exposes a couple of problems: 1. CONFIG_ORION has been removed from the main MIPS config.in but is still referenced in drivers/net/config.in. 2. The MIPS config.in sets CONFIG_AU1000 but does not reference it, then references CONFIG_AU1000_UART without ever setting it. This probably indicates that one of these is a mistake. I have already written help entries for three other symbols CONFIG_DDB5477, CONFIG_QTRONIX_KEYBOARD, and CONFIG_AGP_SWORKS. Would responsible maintainers please supply help entries for the above? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. - 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/
Cross-reference analysis reveals problems in 2.4.6pre9
According to my cross-reference generator, the following symbols have missing help in 2.4.6-pre9: CONFIG_AU1000_UART CONFIG_BLUEZ_L2CAP CONFIG_DDB5477 CONFIG_EVB_PCI1 CONFIG_FORWARD_KEYBOARD CONFIG_GDB_CONSOLE CONFIG_HD64465_IOBASE CONFIG_IT8172_REVC CONFIG_IT8172_SCR0 CONFIG_IT8172_SCR1 CONFIG_LL_DEBUG CONFIG_MAPLE CONFIG_MAPLE_KEYBOARD CONFIG_MAPLE_MOUSE CONFIG_MIDI_VIA82CXXX CONFIG_MIPS_EV64120 CONFIG_MIPS_EV96100 CONFIG_MIPS_ITE8172 CONFIG_MIPS_IVR CONFIG_MIPS_PB1000 CONFIG_MIPS_UNCACHED CONFIG_MTD_OCELOT CONFIG_NINO CONFIG_NINO_16MB CONFIG_NINO_4MB CONFIG_NINO_8MB CONFIG_ORION CONFIG_SH_7751_SOLUTION_ENGINE CONFIG_ST40_LMI_MEMORY CONFIG_SYSCLK_100 CONFIG_SYSCLK_75 CONFIG_SYSCLK_83 CONFIG_TULIP_MMIO This list exposes a couple of problems: 1. CONFIG_ORION has been removed from the main MIPS config.in but is still referenced in drivers/net/config.in. 2. The MIPS config.in sets CONFIG_AU1000 but does not reference it, then references CONFIG_AU1000_UART without ever setting it. This probably indicates that one of these is a mistake. I have already written help entries for three other symbols CONFIG_DDB5477, CONFIG_QTRONIX_KEYBOARD, and CONFIG_AGP_SWORKS. Would responsible maintainers please supply help entries for the above? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns. -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, Urban Delinquency and Substance Abuse, August 1995. - 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/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
Steven J. Hill [EMAIL PROTECTED]: I can fill in the blanks on all of these for you. I won't clutter up the mailing list with the complete descriptions. That would be excellent. Please do! -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. I like a little rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787 - 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/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse [EMAIL PROTECTED]: [EMAIL PROTECTED] said: According to my cross-reference generator, the following symbols have missing help in 2.4.6-pre9: Please fix your cross-reference generator as previously discussed before posting these lists again. I put the symbols we discussed previously on my ignore list. What's your beef this time? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - 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/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse [EMAIL PROTECTED]: Upon further investigation, it seems I was mistaken. I apologise for my tone. Accepted. I wish more people had the grace you do, to apologize when you know you've been mistaken or unfair; it would make this list a better place. Momenco Ocelot boot flash device CONFIG_MTD_OCELOT This enables access routines for the boot flash device and for the NVRAM on the Momenco Ocelot board. If you have one of these boards and would like access to either of these, say 'Y'. Incorporated. I have also received mail from someone who can fill in the new MIPS entries, so initial results from the posting are quite good. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The direct use of physical force is so poor a solution to the problem of limited resources that it is commonly employed only by small children and great nations. -- David Friedman - 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/
Re: Missing help entries in 2.4.6pre5
Nicolas Pitre <[EMAIL PROTECTED]>:
> > CONFIG_XSCALE_IQ80310
>
> 1- This symbol is mine;
> 2- It is part of 2.4.6-pre5 only as a dependency argument, with no
>point where a value is actually assigned to it;
> 3- It is likely to be different when the actual question for which the
>user need an help text is merged into the mainline kernel.
>
> So you can safely ignore it for now.
I've put it on my ignore list.
> Maybe it could be a good thing for your tool to ignore missing help text for
> symbols that don't get enabled interactively by the user?
It already does that for derivations (in CML1, define_*). The real problem
here is that my report generators aren't smart enough to tell when a CML1
symbol is referenced in a CML1 config but never set. That problem could be
solved, but it's unusual that I don't think it's worth the effort.
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
-- Thomas Jefferson, 1823
-
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/
Re: Controversy over dynamic linking -- how to end the panic
Andrew Pimlott <[EMAIL PROTECTED]>:
> On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote:
> > IANAL, but I believe that Linus's position as anthology copyright holder
> > makes him privileged in this respect.
>
> Regardless of what you find in the books, recall that Linus has
> stated that decentralizing the copyright of Linux was a goal, so you
> may not find him willing to claim an "anthology copyright" (if such
> a thing even applies to the kernel, which in my NAL opinion, it does
> not).
Linus *is*, however, implicitly claiming the authority to make license
policy on behalf of the other copyright holders in cases where the GPL
is unclear.
In COPYING, Linus says that that the version of GPL applying to the
kernel is v2 unless explicitly otherwise stated. He has also already
issued the interpretation that normal system calls from userland do
not create a derivation relationship.
I consider Linus to have the moral right to make these decisions, whether
or not the law gives him a formal legal right to do so. All I have done
is propose that he be more explicit about his policy in order to prevent
needless confusion and nervousness.
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
-- Jeff Snyder
-
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/
Re: Missing help entries in 2.4.6pre5
Russell King <[EMAIL PROTECTED]>: > On Thu, Jun 21, 2001 at 03:49:34PM -0400, Eric S. Raymond wrote: > > CONFIG_XSCALE_IQ80310 > > I think we've covered this one before. Yes. But if I don't ask, I won't ncessarily know when it changes status. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 - 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/
Re: Controversy over dynamic linking -- how to end the panic
Alan Cox <[EMAIL PROTECTED]>: > > >As copyright holder of the Linux kernel, Linus is the only person with > > >standing to sue for license violation. Therefore, when he says > > He's copyright holder of parts of it. The FSF is also a copyright holder of > oddments, as are many people. IANAL, but I believe that Linus's position as anthology copyright holder makes him privileged in this respect. My wife, who *is* an attorney, will be researching this. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report - 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/
Controversy over dynamic linking -- how to end the panic
As you know, there's been another flap recently about the GPL status of loadable kernel modules. You have a note that touches on this in the kernel COPYING file, but it is not sufficient to resolve the questions that keep coming up. Earlier today I was contacted by a principal at a well-known Linux company who was in a mild panic over recent arguments by Alan Cox and David Miller. This company (not VA or Red Hat, BTW) fears that their customers will run from Linux if they get the idea that linking drivers to the kernel might force them open. I wrote back as follows: >Alan's posting beginning "Linus opinion on this is irrelevant" is not a >`perspective' that he can be argued out of. He is not arguing about whether >allowing proprietary binary modules is good, bad, or indifferent. > >Alan is merely stating legal facts as he understands them -- and, in >fact, I agree with his assessment. The key question is whether the >particular kind of linking involved with loading binary modules >propagates derivative-work status under copyright law. This is a legal >question a court may rule on someday. Until one does, anyone who >relies on such linking is taking a legal risk. > >Alan is not quite right that Linus's opinion is irrelevant. It is irrelevant >to the underlying legal question, but not to the associated business risk. > >As copyright holder of the Linux kernel, Linus is the only person with >standing to sue for license violation. Therefore, when he says >"binary modules are OK", he is stating a policy intention which your >customers may include in their evaluation of legal risk. This means >that in order for them to lose, a court must rule that module linking >propagates derivative-work status *and* Linus must reverse himself and >sue. So I'm proposing a solution. We can't resolve the underlying legal question yet, but you can make your policy clearer. In the existing kernel COPYING file: > NOTE! This copyright does *not* cover user programs that use kernel > services by normal system calls - this is merely considered normal use > of the kernel, and does *not* fall under the heading of "derived work". > Also note that the GPL below is copyrighted by the Free Software > Foundation, but the instance of code that it refers to (the Linux > kernel) is copyrighted by me and others who actually wrote it. I suggest replacing this with something resembling the following: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of "derivative work" has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I believe this would express the present policy clearly enough to soothe jittery nerves at a lot of companies that are worried about this issue. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Government: If you refuse to pay unjust taxes, your property will be confiscated. If you attempt to defend your property, you will be arrested. If you resist arrest, you will be clubbed. If you defend yourself against clubbing, you will be shot dead. These procedures are known as the Rule of Law. -- Edward Abbey - 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/
Controversy over dynamic linking -- how to end the panic
As you know, there's been another flap recently about the GPL status of loadable kernel modules. You have a note that touches on this in the kernel COPYING file, but it is not sufficient to resolve the questions that keep coming up. Earlier today I was contacted by a principal at a well-known Linux company who was in a mild panic over recent arguments by Alan Cox and David Miller. This company (not VA or Red Hat, BTW) fears that their customers will run from Linux if they get the idea that linking drivers to the kernel might force them open. I wrote back as follows: Alan's posting beginning Linus opinion on this is irrelevant is not a `perspective' that he can be argued out of. He is not arguing about whether allowing proprietary binary modules is good, bad, or indifferent. Alan is merely stating legal facts as he understands them -- and, in fact, I agree with his assessment. The key question is whether the particular kind of linking involved with loading binary modules propagates derivative-work status under copyright law. This is a legal question a court may rule on someday. Until one does, anyone who relies on such linking is taking a legal risk. Alan is not quite right that Linus's opinion is irrelevant. It is irrelevant to the underlying legal question, but not to the associated business risk. As copyright holder of the Linux kernel, Linus is the only person with standing to sue for license violation. Therefore, when he says binary modules are OK, he is stating a policy intention which your customers may include in their evaluation of legal risk. This means that in order for them to lose, a court must rule that module linking propagates derivative-work status *and* Linus must reverse himself and sue. So I'm proposing a solution. We can't resolve the underlying legal question yet, but you can make your policy clearer. In the existing kernel COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. I suggest replacing this with something resembling the following: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of derivative work has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I believe this would express the present policy clearly enough to soothe jittery nerves at a lot of companies that are worried about this issue. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government: If you refuse to pay unjust taxes, your property will be confiscated. If you attempt to defend your property, you will be arrested. If you resist arrest, you will be clubbed. If you defend yourself against clubbing, you will be shot dead. These procedures are known as the Rule of Law. -- Edward Abbey - 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/
Re: Missing help entries in 2.4.6pre5
Nicolas Pitre [EMAIL PROTECTED]: CONFIG_XSCALE_IQ80310 1- This symbol is mine; 2- It is part of 2.4.6-pre5 only as a dependency argument, with no point where a value is actually assigned to it; 3- It is likely to be different when the actual question for which the user need an help text is merged into the mainline kernel. So you can safely ignore it for now. I've put it on my ignore list. Maybe it could be a good thing for your tool to ignore missing help text for symbols that don't get enabled interactively by the user? It already does that for derivations (in CML1, define_*). The real problem here is that my report generators aren't smart enough to tell when a CML1 symbol is referenced in a CML1 config but never set. That problem could be solved, but it's unusual that I don't think it's worth the effort. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The day will come when the mystical generation of Jesus by the Supreme Being as his father, in the womb of a virgin, will be classed with the fable of the generation of Minerva in the brain of Jupiter. -- Thomas Jefferson, 1823 - 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/
Re: Missing help entries in 2.4.6pre5
Russell King [EMAIL PROTECTED]: On Thu, Jun 21, 2001 at 03:49:34PM -0400, Eric S. Raymond wrote: CONFIG_XSCALE_IQ80310 I think we've covered this one before. Yes. But if I don't ask, I won't ncessarily know when it changes status. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, Advice to the Privileged Orders, 1792-93 - 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/
Re: Controversy over dynamic linking -- how to end the panic
Andrew Pimlott [EMAIL PROTECTED]: On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote: IANAL, but I believe that Linus's position as anthology copyright holder makes him privileged in this respect. Regardless of what you find in the books, recall that Linus has stated that decentralizing the copyright of Linux was a goal, so you may not find him willing to claim an anthology copyright (if such a thing even applies to the kernel, which in my NAL opinion, it does not). Linus *is*, however, implicitly claiming the authority to make license policy on behalf of the other copyright holders in cases where the GPL is unclear. In COPYING, Linus says that that the version of GPL applying to the kernel is v2 unless explicitly otherwise stated. He has also already issued the interpretation that normal system calls from userland do not create a derivation relationship. I consider Linus to have the moral right to make these decisions, whether or not the law gives him a formal legal right to do so. All I have done is propose that he be more explicit about his policy in order to prevent needless confusion and nervousness. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder - 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/
Re: Controversy over dynamic linking -- how to end the panic
Alan Cox [EMAIL PROTECTED]: As copyright holder of the Linux kernel, Linus is the only person with standing to sue for license violation. Therefore, when he says He's copyright holder of parts of it. The FSF is also a copyright holder of oddments, as are many people. IANAL, but I believe that Linus's position as anthology copyright holder makes him privileged in this respect. My wife, who *is* an attorney, will be researching this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report - 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/
Kernel configuration. It's not just a job, it's an adventure!
ve -- save the configuration (follow with a filename).
xyzzy -- toggle suppression flag.
quit -- quit, discarding changes.
exit -- exit, saving the configuration.
You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down.
> quit
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
-- Frederic Bastiat, "The Law"
-
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/
Kernel configuration. It's not just a job, it's an adventure!
). xyzzy -- toggle suppression flag. quit -- quit, discarding changes. exit -- exit, saving the configuration. You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down. quit -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a What, then is law [government]? It is the collective organization of the individual right to lawful defense. -- Frederic Bastiat, The Law - 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/
Re: Configure.help is complete
Arjan van de Ven <[EMAIL PROTECTED]>: > > Linux Kernel v2.4.5-ac5 Configuration > > CML1 > > > > Bottom of IDE, ATA and ATAPI Block devices; > > > > < > Support Promise software RAID (NEW) -> Help > > There is no help available for this kernel option. > > How about > "Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller > and want linux to use the softwarraid feature of this card. > This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names. > > If you have a Promise Fasttrak(tm) card but do not use the BIOS provided > raid feature, say "N". Um, tell me what the symbol name and prompt for this is, please? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond [President Clinton] boasts about 186,000 people denied firearms under the Brady Law rules. The Brady Law has been in force for three years. In that time, they have prosecuted seven people and put three of them in prison. You know, the President has entertained more felons than that at fundraising coffees in the White House, for Pete's sake." -- Charlton Heston, FOX News Sunday, 18 May 1997 - 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/
Re: Configure.help is complete
José Luis Domingo López <[EMAIL PROTECTED]>: > Would it be great to have a similar documentation for those hundreds of > "files" under /proc ?. Yes, this would be wonderful. Are you volunteering to write it? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 - 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/
Configure.help is complete
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help. This does not, of course, mean the job of maintaining Configure.help is done; symbols will be added and dropped in the future (there are a handful of new ones in ac5, all now documented), and some existing entries could stand to be rewritten and expanded. But we have passed a milestone -- maintainance will now be a matter of keeping the boat bailed rather than trying to ignore a hole in the side. Thanks to all the contributors who helped put together the over 550 entries necessary to catch up, too many to name here. The result is available at: http://www.tuxedo.org/~esr/cml2/Configure.help.gz Though carried on the CML2 project page, it can be used with CML1 and is current with respect to both Linus's tree and Alan's. I now have two requests of Linus and Alan: 1. Please pick up this work now. It is a really substantial improvement on what you have in your trees, incorporating it cannot break anything, and you'll help prevent unnecessary hassles due to clashing patches in the future. 2. Please make a policy of rejecting patches that add new configuration symbols without also adding an explanatory Configure.help entry -- and please *announce* that you will do so. We can raise our standards now, and for the sake of having a well-documentated kernel and configuration system I submit that we ought to. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - 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/
Re: Configure.help is complete
Arjan van de Ven [EMAIL PROTECTED]: Linux Kernel v2.4.5-ac5 Configuration CML1 Bottom of IDE, ATA and ATAPI Block devices; Support Promise software RAID (NEW) - Help There is no help available for this kernel option. How about Say Y or M if you have a Promise Fasttrak (tm) Raid controller and want linux to use the softwarraid feature of this card. This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names. If you have a Promise Fasttrak(tm) card but do not use the BIOS provided raid feature, say N. Um, tell me what the symbol name and prompt for this is, please? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a [President Clinton] boasts about 186,000 people denied firearms under the Brady Law rules. The Brady Law has been in force for three years. In that time, they have prosecuted seven people and put three of them in prison. You know, the President has entertained more felons than that at fundraising coffees in the White House, for Pete's sake. -- Charlton Heston, FOX News Sunday, 18 May 1997 - 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/
Re: Configure.help is complete
José Luis Domingo López [EMAIL PROTECTED]: Would it be great to have a similar documentation for those hundreds of files under /proc ?. Yes, this would be wonderful. Are you volunteering to write it? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 - 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/
Configure.help is complete
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help. This does not, of course, mean the job of maintaining Configure.help is done; symbols will be added and dropped in the future (there are a handful of new ones in ac5, all now documented), and some existing entries could stand to be rewritten and expanded. But we have passed a milestone -- maintainance will now be a matter of keeping the boat bailed rather than trying to ignore a hole in the side. Thanks to all the contributors who helped put together the over 550 entries necessary to catch up, too many to name here. The result is available at: http://www.tuxedo.org/~esr/cml2/Configure.help.gz Though carried on the CML2 project page, it can be used with CML1 and is current with respect to both Linus's tree and Alan's. I now have two requests of Linus and Alan: 1. Please pick up this work now. It is a really substantial improvement on what you have in your trees, incorporating it cannot break anything, and you'll help prevent unnecessary hassles due to clashing patches in the future. 2. Please make a policy of rejecting patches that add new configuration symbols without also adding an explanatory Configure.help entry -- and please *announce* that you will do so. We can raise our standards now, and for the sake of having a well-documentated kernel and configuration system I submit that we ought to. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - 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/
Only 5 undocumented configuration symbols left
The current list of symbols with missing help is very short. Here it is: PPC port: CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_IRQ_ALL_CPUS CONFIG_USE_MDIO CRIS port: CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C Let's finish this off, people! -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, "A Treatise Concerning Civil Government" - 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/
Re: Remaining undocumented Configure.help symbols
Harald Welte <[EMAIL PROTECTED]>: > On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote: > > > CONFIG_NET_CLS_TCINDEX > > If you say Y here, you will be able to classify outgoing packets > according to the tc_index field of the skb. You will want this > feature if you want to implement Differentiates Services useing > sch_dsmark. If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt Looks good. > > CONFIG_NET_SCH_INGRESS > > If you say Y here, you will be able to police incoming bandwidth > and drop packets when this bandwidth exceeds your desired rate. > If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt I'm going to assume that the cls_tcindex.o in the second entry is a cut'n'paste error and should read sch_ingress.o. Should the CLS_POLICE entry, then, read like this? Traffic policing (needed for in/egress) CONFIG_NET_CLS_POLICE Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) - 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/
Re: Remaining undocumented Configure.help symbols
Harald Welte [EMAIL PROTECTED]: On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote: CONFIG_NET_CLS_TCINDEX If you say Y here, you will be able to classify outgoing packets according to the tc_index field of the skb. You will want this feature if you want to implement Differentiates Services useing sch_dsmark. If unsure, say Y. This code is also available as a module called cls_tcindex.o ( = code which can be inserted in and removed from the running kernel whenever you want). If you want to compile it as a module, say MM here and read Documentation/modules.txt Looks good. CONFIG_NET_SCH_INGRESS If you say Y here, you will be able to police incoming bandwidth and drop packets when this bandwidth exceeds your desired rate. If unsure, say Y. This code is also available as a module called cls_tcindex.o ( = code which can be inserted in and removed from the running kernel whenever you want). If you want to compile it as a module, say MM here and read Documentation/modules.txt I'm going to assume that the cls_tcindex.o in the second entry is a cut'n'paste error and should read sch_ingress.o. Should the CLS_POLICE entry, then, read like this? Traffic policing (needed for in/egress) CONFIG_NET_CLS_POLICE Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) - 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/
Only 5 undocumented configuration symbols left
The current list of symbols with missing help is very short. Here it is: PPC port: CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_IRQ_ALL_CPUS CONFIG_USE_MDIO CRIS port: CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C Let's finish this off, people! -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, A Treatise Concerning Civil Government - 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/
Re: [kbuild-devel] Re: Configure.help entries wanted
Philip Blundell <[EMAIL PROTECTED]>:
> >CONFIG_ARCH_FTVPCI
> >CONFIG_ARCH_NEXUSPCI
>
> These symbols both refer to the same thing (the latter is an obsolete name).
> I guess appropriate text would be something like:
>
> Say Y here if you intend to run this kernel on a FutureTV (nee Nexus
> Electronics) StrongARM PCI card.
Hm. They're both in active use in 2.4.5pre4. My cross-referencer shows
CONFIG_ARCH_NEXUSPCI: arch/arm/config.in arch/arm/boot/Makefile
arch/arm/kernel/entry-armv.S arch/arm/kernel/arch.c
snark:~/src/linux$ scripts/kxref.py -f "o&~h&~x" -n defconfig | grep FTVPCI
Reading cross-reference database...done.
CONFIG_ARCH_FTVPCI: arch/arm/Makefile arch/arm/config.in
arch/arm/boot/compressed/Makefile arch/arm/kernel/Makefile arch/arm/kernel/bios32.c
arch/arm/kernel/debug-armv.S arch/arm/def-configs/clps7500 arch/arm/def-configs/shark
On further investigation I find that neither of these symbols is actually
set in the ARM config file! This is kind of a mess. Is it going to be
fixed in the next merge?
(They're not the only dead symbols. CONFIG_TBOX and CONFIG_SHARK don't
have associated questions either.)
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
Courage is resistance of fear, mastery of fear, not absence of fear.
-
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/
Re: Configure.help entries wanted
Keith Owens <[EMAIL PROTECTED]>: > I claim my erudition prize (do I get steak knives with that?). Results doubtful. Consult Magic 8-Ball again :-). I'm going to critique these individually pour encourager les autres. > +Disable IA-64 Virtual Hash Page Table > +CONFIG_DISABLE_VHPT > + The Virtual Hash Page Table (VHPT) enhances virtual address > + translation performance. Normally you want the VHPT active but you > + can select this option to disable the VHPT for debugging. If you're > + unsure, answer N. Excellent! Second sentence a good example of motivation. > +McKinley A-step specific code > +CONFIG_MCKINLEY_ASTEP_SPECIFIC > + Select this option to build a kernel for an IA64 McKinley system > + with any A-stepping CPU. > + > +McKinley A0/A1-step specific code > +CONFIG_MCKINLEY_A0_SPECIFIC > + Select this option to build a kernel for an IA64 McKinley system > + with an A0 or A1 stepping CPU. Ah, now I could have written these. What I was hoping for was extra information analogous to what's in these: Enable Itanium B-step specific code CONFIG_ITANIUM_BSTEP_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B-step CPU. You have a B-step CPU if the "revision" field in /proc/cpuinfo has a value in the range from 1 to 4. Enable Itanium B0-step specific code CONFIG_ITANIUM_B0_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B0-step CPU. You have a B0-step CPU if the "revision" field in /proc/cpuinfo is 1. Is there a value range in /proc/cpuinfo that tells you you have an A/A0 step? > +IA64 compare-and-exchange bug checking > +CONFIG_IA64_DEBUG_CMPXCHG > + Selecting this option turns on bug checking for the IA64 > + compare-and-exchange instructions. This is slow! If you're unsure, > + select N. > + > +IA64 IRQ bug checking > +CONFIG_IA64_DEBUG_IRQ > + Selecting this option turns on bug checking for the IA64 irq_save and > + restore instructions. This is slow! If you're unsure, select N. These would be much improved by some indication of what IA64 variants or mask steppings have these problems. > +IA64 Early printk support > +CONFIG_IA64_EARLY_PRINTK > + Selecting this option uses the VGA screen for printk() output before > + the consoles are initialised. It is useful for debugging problems > + early in the boot process, but only if you have a VGA screen > + attached. If you're unsure, select N. Good! > +IA64 Print Hazards > +CONFIG_IA64_PRINT_HAZARDS > + Selecting this option prints more information for Illegal Dependency > + Faults, that is, for Read after Write, Write after Write or Write > + after Read violations. This option is ignored if you are compiling > + for an Itanium A step processor (CONFIG_ITANIUM_ASTEP_SPECIFIC). If > + you're unsure, select Y. Excellent! This is a fine start. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express." -- Father Gregory Nazianzen, 381 AD - 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/
Re: Configure.help entries wanted
Keith Owens [EMAIL PROTECTED]: I claim my erudition prize (do I get steak knives with that?). Results doubtful. Consult Magic 8-Ball again :-). I'm going to critique these individually pour encourager les autres. +Disable IA-64 Virtual Hash Page Table +CONFIG_DISABLE_VHPT + The Virtual Hash Page Table (VHPT) enhances virtual address + translation performance. Normally you want the VHPT active but you + can select this option to disable the VHPT for debugging. If you're + unsure, answer N. Excellent! Second sentence a good example of motivation. +McKinley A-step specific code +CONFIG_MCKINLEY_ASTEP_SPECIFIC + Select this option to build a kernel for an IA64 McKinley system + with any A-stepping CPU. + +McKinley A0/A1-step specific code +CONFIG_MCKINLEY_A0_SPECIFIC + Select this option to build a kernel for an IA64 McKinley system + with an A0 or A1 stepping CPU. Ah, now I could have written these. What I was hoping for was extra information analogous to what's in these: Enable Itanium B-step specific code CONFIG_ITANIUM_BSTEP_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B-step CPU. You have a B-step CPU if the revision field in /proc/cpuinfo has a value in the range from 1 to 4. Enable Itanium B0-step specific code CONFIG_ITANIUM_B0_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B0-step CPU. You have a B0-step CPU if the revision field in /proc/cpuinfo is 1. Is there a value range in /proc/cpuinfo that tells you you have an A/A0 step? +IA64 compare-and-exchange bug checking +CONFIG_IA64_DEBUG_CMPXCHG + Selecting this option turns on bug checking for the IA64 + compare-and-exchange instructions. This is slow! If you're unsure, + select N. + +IA64 IRQ bug checking +CONFIG_IA64_DEBUG_IRQ + Selecting this option turns on bug checking for the IA64 irq_save and + restore instructions. This is slow! If you're unsure, select N. These would be much improved by some indication of what IA64 variants or mask steppings have these problems. +IA64 Early printk support +CONFIG_IA64_EARLY_PRINTK + Selecting this option uses the VGA screen for printk() output before + the consoles are initialised. It is useful for debugging problems + early in the boot process, but only if you have a VGA screen + attached. If you're unsure, select N. Good! +IA64 Print Hazards +CONFIG_IA64_PRINT_HAZARDS + Selecting this option prints more information for Illegal Dependency + Faults, that is, for Read after Write, Write after Write or Write + after Read violations. This option is ignored if you are compiling + for an Itanium A step processor (CONFIG_ITANIUM_ASTEP_SPECIFIC). If + you're unsure, select Y. Excellent! This is a fine start. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express. -- Father Gregory Nazianzen, 381 AD - 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/
Re: [kbuild-devel] Re: Configure.help entries wanted
Philip Blundell [EMAIL PROTECTED]: CONFIG_ARCH_FTVPCI CONFIG_ARCH_NEXUSPCI These symbols both refer to the same thing (the latter is an obsolete name). I guess appropriate text would be something like: Say Y here if you intend to run this kernel on a FutureTV (nee Nexus Electronics) StrongARM PCI card. Hm. They're both in active use in 2.4.5pre4. My cross-referencer shows CONFIG_ARCH_NEXUSPCI: arch/arm/config.in arch/arm/boot/Makefile arch/arm/kernel/entry-armv.S arch/arm/kernel/arch.c snark:~/src/linux$ scripts/kxref.py -f o~h~x -n defconfig | grep FTVPCI Reading cross-reference database...done. CONFIG_ARCH_FTVPCI: arch/arm/Makefile arch/arm/config.in arch/arm/boot/compressed/Makefile arch/arm/kernel/Makefile arch/arm/kernel/bios32.c arch/arm/kernel/debug-armv.S arch/arm/def-configs/clps7500 arch/arm/def-configs/shark On further investigation I find that neither of these symbols is actually set in the ARM config file! This is kind of a mess. Is it going to be fixed in the next merge? (They're not the only dead symbols. CONFIG_TBOX and CONFIG_SHARK don't have associated questions either.) -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Courage is resistance of fear, mastery of fear, not absence of fear. - 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/
What's up with GT96100 in the MIPS config file?
Near line 55 of drivers/net/Config.in there is code that reads like this: if [ "$CONFIG_MIPS_GT96100" = "y" ]; then bool ' MIPS GT96100 Ethernet support' CONFIG_MIPS_GT96100ETH fi All very well except that CONFIG_MIPS_GT96100 is never set (or even used) anywhere else. My cross-reference generator shows this: snark:~/src/linux$ scripts/kxref.py | grep GT96 CONFIG_MIPS_GT96100: drivers/net/Config.in CONFIG_MIPS_GT96100ETH: drivers/net/Makefile drivers/net/Config.in drivers/net/gt96100eth.c The simplest guess is that the guard part is just wrong. Can anybody shed any light on this? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - 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/
What's up with GT96100 in the MIPS config file?
Near line 55 of drivers/net/Config.in there is code that reads like this: if [ $CONFIG_MIPS_GT96100 = y ]; then bool ' MIPS GT96100 Ethernet support' CONFIG_MIPS_GT96100ETH fi All very well except that CONFIG_MIPS_GT96100 is never set (or even used) anywhere else. My cross-reference generator shows this: snark:~/src/linux$ scripts/kxref.py | grep GT96 CONFIG_MIPS_GT96100: drivers/net/Config.in CONFIG_MIPS_GT96100ETH: drivers/net/Makefile drivers/net/Config.in drivers/net/gt96100eth.c The simplest guess is that the guard part is just wrong. Can anybody shed any light on this? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - 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/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > I'm going to assume for now that CML2 saves two files - one storing a > relatively small number of symbols (which is strictly limited to those > explicitly set by the user), and one containing the full set for > consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 - 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/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton [EMAIL PROTECTED]: I'm going to assume for now that CML2 saves two files - one storing a relatively small number of symbols (which is strictly limited to those explicitly set by the user), and one containing the full set for consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, My First Impression of the U.S.A., 1921 - 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/
Re: Background to the argument about CML2 design philosophy
Urban Widmark <[EMAIL PROTECTED]>: > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), - 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/
Dead symbols in CMl1
I think I've identified a number of dead symbols. Here's a list: CONFIG_BAGETBSM (Baget Backplane Shared Memory support) Set in arch/mips64/config.in, not used anywhere. CONFIG_ACPI_INTERPRETER (ACPI interpreter) Set in arch/ia64/config.in, not used anywhere. CONFIG_BINFMT_JAVA (Kernel support for JAVA binaries) Set in arch/parisc/config.in and arch/cris/config.in, not used anywhere. CONFIG_SCSI_DECSII (DEC SII SCSI Driver) Set in drivers/scsi/Config.in, not used anywhere. CONFIG_PROFILE (Enable traffic profiling) CONFIG_PROFILE_SHIFT (Profile shift count) Set in arch/cris/config.in, not used anywhere. CONFIG_SERIAL_21285_OLD (Use /dev/ttyS0 device) Set in drivers/char/Config.in, not used anywhere The following patch removes them cleanly: Diffs between last version checked in and current workfile(s): --- arch/cris/config.in 2001/05/22 00:55:28 1.1 +++ arch/cris/config.in 2001/05/22 00:56:22 @@ -20,9 +20,6 @@ bool 'System V IPC' CONFIG_SYSVIPC tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA -fi bool 'Use kernel gdb debugger' CONFIG_ETRAX_KGDB @@ -232,8 +229,4 @@ comment 'Kernel hacking' #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC -bool 'Kernel profiling support' CONFIG_PROFILE -if [ "$CONFIG_PROFILE" = "y" ]; then - int ' Profile shift count' CONFIG_PROFILE_SHIFT 2 -fi endmenu --- arch/ia64/config.in 2001/05/22 00:51:05 1.1 +++ arch/ia64/config.in 2001/05/22 00:51:26 @@ -89,7 +89,6 @@ if [ "$CONFIG_ACPI_KERNEL_CONFIG" = "y" ]; then define_bool CONFIG_PM y define_bool CONFIG_ACPI y - define_bool CONFIG_ACPI_INTERPRETER y fi fi --- arch/mips64/config.in 2001/05/22 00:50:33 1.1 +++ arch/mips64/config.in 2001/05/22 00:50:44 @@ -183,7 +183,6 @@ fi if [ "$CONFIG_BAGET_MIPS" = "y" ]; then tristate 'Baget AMD LANCE support' CONFIG_BAGETLANCE -tristate 'Baget Backplane Shared Memory support' CONFIG_BAGETBSM fi if [ "$CONFIG_ATM" = "y" ]; then source drivers/atm/Config.in --- arch/parisc/config.in 2001/05/22 00:55:04 1.1 +++ arch/parisc/config.in 2001/05/22 00:55:14 @@ -68,9 +68,6 @@ tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA -fi endmenu --- drivers/char/Config.in 2001/05/22 00:56:44 1.1 +++ drivers/char/Config.in 2001/05/22 00:56:56 @@ -63,9 +63,6 @@ if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then bool 'DC21285 serial port support' CONFIG_SERIAL_21285 if [ "$CONFIG_SERIAL_21285" = "y" ]; then - if [ "$CONFIG_OBSOLETE" = "y" ]; then - bool ' Use /dev/ttyS0 device (OBSOLETE)' CONFIG_SERIAL_21285_OLD - fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi fi --- drivers/scsi/Config.in 2001/05/22 00:55:54 1.1 +++ drivers/scsi/Config.in 2001/05/22 00:56:01 @@ -39,7 +39,6 @@ if [ "$CONFIG_TC" = "y" ]; then dep_tristate 'DEC NCR53C94 Scsi Driver' CONFIG_SCSI_DECNCR $CONFIG_SCSI fi - dep_tristate 'DEC SII Scsi Driver' CONFIG_SCSI_DECSII $CONFIG_SCSI fi if [ "$CONFIG_PCI" = "y" ]; then End of diffs. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. - 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/
Re: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Speaking from the perspective of a user of the CML tools, rather
> than as a developer, all I've been trying to say is this: When I
> type "make menuconfig" or "make oldconfig" in the future, I want to
> see the same interface and the same results that I've always seen,
> because it's always worked for me in the past.
Visual details will differ, but I've been careful about maintaining
functional compatibility. There was a phase of the development during
which I was mostly processing feature requests from people who wanted
features of the old system that I had not properly understood (such as
the NEW tag). That phase ended almost a month ago. Nobody who has
actually tried the CML2 tools more recently has reported that the UI
changes present any difficulty.
CML2 drops its configuration results in the same place, in the same
formats, as CML1. So you should in fact be able to type `make menuconfig'
and `make oldconfig' with good results. Have you actually tried this?
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
The right of the citizens to keep and bear arms has justly been considered as
the palladium of the liberties of a republic; since it offers a strong moral
check against usurpation and arbitrary power of rulers; and will generally,
even if these are successful in the first instance, enable the people to resist
and triumph over them."
-- Supreme Court Justice Joseph Story of the John Marshall Court
-
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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Brent D. Norris <[EMAIL PROTECTED]>: > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Tom Rini <[EMAIL PROTECTED]>: > python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script > uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. > Which brings up another point, RedHat (7.1?) and Debian/woody both have the > option of having python2 around. Anyone know about mandrake? My point is > that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. > Eric, would it be easy/possible to go back to requiring python 1.5.x for > CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Because it is evidently confusing the issue. Perhaps because it sounds like > you were intending to feed Linus large patches for 2.5.[12] which effect > _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. > Have patience - let the less contentious part of CML2 go in first, and then > we can deal with the other stuff later, once CML2 has been accepted (however > grudgingly in some cases) by developers. I don't think there is a "less contentious" part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. > > The engine is working. Why is it not yet time to discuss ruleset design > > and modes? > > For a man who claims to hack social systems, that's an incredibly naïve > question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated "fsck Python..." after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: Because it is evidently confusing the issue. Perhaps because it sounds like you were intending to feed Linus large patches for 2.5.[12] which effect _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. Have patience - let the less contentious part of CML2 go in first, and then we can deal with the other stuff later, once CML2 has been accepted (however grudgingly in some cases) by developers. I don't think there is a less contentious part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. The engine is working. Why is it not yet time to discuss ruleset design and modes? For a man who claims to hack social systems, that's an incredibly naïve question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated fsck Python... after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Tom Rini [EMAIL PROTECTED]: python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones - 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/
Re: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] [EMAIL PROTECTED]: Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type make menuconfig or make oldconfig in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them. -- Supreme Court Justice Joseph Story of the John Marshall Court - 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/
Dead symbols in CMl1
I think I've identified a number of dead symbols. Here's a list: CONFIG_BAGETBSM (Baget Backplane Shared Memory support) Set in arch/mips64/config.in, not used anywhere. CONFIG_ACPI_INTERPRETER (ACPI interpreter) Set in arch/ia64/config.in, not used anywhere. CONFIG_BINFMT_JAVA (Kernel support for JAVA binaries) Set in arch/parisc/config.in and arch/cris/config.in, not used anywhere. CONFIG_SCSI_DECSII (DEC SII SCSI Driver) Set in drivers/scsi/Config.in, not used anywhere. CONFIG_PROFILE (Enable traffic profiling) CONFIG_PROFILE_SHIFT (Profile shift count) Set in arch/cris/config.in, not used anywhere. CONFIG_SERIAL_21285_OLD (Use /dev/ttyS0 device) Set in drivers/char/Config.in, not used anywhere The following patch removes them cleanly: Diffs between last version checked in and current workfile(s): --- arch/cris/config.in 2001/05/22 00:55:28 1.1 +++ arch/cris/config.in 2001/05/22 00:56:22 @@ -20,9 +20,6 @@ bool 'System V IPC' CONFIG_SYSVIPC tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF -if [ $CONFIG_EXPERIMENTAL = y ]; then - tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA -fi bool 'Use kernel gdb debugger' CONFIG_ETRAX_KGDB @@ -232,8 +229,4 @@ comment 'Kernel hacking' #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC -bool 'Kernel profiling support' CONFIG_PROFILE -if [ $CONFIG_PROFILE = y ]; then - int ' Profile shift count' CONFIG_PROFILE_SHIFT 2 -fi endmenu --- arch/ia64/config.in 2001/05/22 00:51:05 1.1 +++ arch/ia64/config.in 2001/05/22 00:51:26 @@ -89,7 +89,6 @@ if [ $CONFIG_ACPI_KERNEL_CONFIG = y ]; then define_bool CONFIG_PM y define_bool CONFIG_ACPI y - define_bool CONFIG_ACPI_INTERPRETER y fi fi --- arch/mips64/config.in 2001/05/22 00:50:33 1.1 +++ arch/mips64/config.in 2001/05/22 00:50:44 @@ -183,7 +183,6 @@ fi if [ $CONFIG_BAGET_MIPS = y ]; then tristate 'Baget AMD LANCE support' CONFIG_BAGETLANCE -tristate 'Baget Backplane Shared Memory support' CONFIG_BAGETBSM fi if [ $CONFIG_ATM = y ]; then source drivers/atm/Config.in --- arch/parisc/config.in 2001/05/22 00:55:04 1.1 +++ arch/parisc/config.in 2001/05/22 00:55:14 @@ -68,9 +68,6 @@ tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC -if [ $CONFIG_EXPERIMENTAL = y ]; then - tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA -fi endmenu --- drivers/char/Config.in 2001/05/22 00:56:44 1.1 +++ drivers/char/Config.in 2001/05/22 00:56:56 @@ -63,9 +63,6 @@ if [ $CONFIG_FOOTBRIDGE = y ]; then bool 'DC21285 serial port support' CONFIG_SERIAL_21285 if [ $CONFIG_SERIAL_21285 = y ]; then - if [ $CONFIG_OBSOLETE = y ]; then - bool ' Use /dev/ttyS0 device (OBSOLETE)' CONFIG_SERIAL_21285_OLD - fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi fi --- drivers/scsi/Config.in 2001/05/22 00:55:54 1.1 +++ drivers/scsi/Config.in 2001/05/22 00:56:01 @@ -39,7 +39,6 @@ if [ $CONFIG_TC = y ]; then dep_tristate 'DEC NCR53C94 Scsi Driver' CONFIG_SCSI_DECNCR $CONFIG_SCSI fi - dep_tristate 'DEC SII Scsi Driver' CONFIG_SCSI_DECSII $CONFIG_SCSI fi if [ $CONFIG_PCI = y ]; then End of diffs. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as a sign of emotional and sexual immaturity. Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own forbidden feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing gun-control laws and trashing the Constitution. - 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/
Re: Background to the argument about CML2 design philosophy
Urban Widmark [EMAIL PROTECTED]: What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...quemadmodum gladius neminem occidit, occidentis telum est. [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca the Younger (ca. 4 BC-65 AD), - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Brent D. Norris [EMAIL PROTECTED]: didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing > behaviour of config options to make that the default, until we've settled > the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789 - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > I think you already have the mechanism required to answer this - in NOVICE > mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - 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/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > One caveat though - not all Macs have SCSI controllers, and not all that do > even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. > >3. The MVME derivations are correct *if* (and only if) you agree to ignore > >the possibility that somebody could want to ignore the onboard hardware, > >plug outboard disk or Ethernet cards into the VME-bus connector, and > >do something like running SCSI-over-ATAPI to the outboard device. > > ...and then someone else mentioned the possibility of f*x0r3d hardware. In > this case, I would say this *isn't* a kernel-configuration issue but one of > being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. > I think the MVME derivations are *perfectly* sensible - if the reference > board and most (read: virtually all) derivatives have those features, turn > them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. > To satisfy some others, you might want to say "Hey, > these guys might want to *explicitly turn off* some of this stuff" - so > provide an option under "Are you insane?" which presents all the "derived" > symbols and allows the hackers to manually turn stuff off. Interesting thought... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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/
Background to the argument about CML2 design philosophy
tboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is "yes, sometimes" is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is "no" will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset. So far, I have to say I'm disappointed in the quality of the debate. Almoist nobody seems to want to think about this tradeoff globally, as a systems design issue. Instead, I'm hearing a lot of reflexive chuntering that we have to do things a certain way because we've always done them a certain way, and who am I to even dare *think* about raising different possibilities? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond [The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 - 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/
Re: CML2 design philosophy heads-up
David Woodhouse <[EMAIL PROTECTED]>:
> On one hand you have dependencies which are present to make life easier for
> Aunt Tillie, by refraining from confusing her with strange questions to
> which the answer is _probably_ 'no'. Like the question of whether she has
> an IDE controller on her MVME board.
>
> One the other hand, you have the dependencies present in the existing CML1
> configuration, which are _absolute_ dependencies - which specify for example
> that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc.
> These dependencies are there to prevent you from enabling combinations of
> options which are utterly meaningless, and usually won't even compile.
There are no `advisory' dependencies in CML2. They're all absolute.
What you call an `advisory' dependency would be simulated by having a
policy symbol for Aunt Tillie mode and writing constraints like this:
require AUNT_TILLIE implies FOO >= BAR
This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING
policy symbols, as hooks for doing things like this.
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
No one who's seen it in action can say the phrase "government help" without
either laughing or crying.
-
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/
Re: CML2 design philosophy heads-up
David Woodhouse <[EMAIL PROTECTED]>: > The dependencies in CML1 are (supposed to > be) absolute - the 'advisory' dependencies you're adding are arguably a > useful feature, but please don't make it possible to confuse the two, and > please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Both oligarch and tyrant mistrust the people, and therefore deprive them of arms." --Aristotle - 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/
Re: CML2 design philosophy heads-up
David Woodhouse [EMAIL PROTECTED]: The dependencies in CML1 are (supposed to be) absolute - the 'advisory' dependencies you're adding are arguably a useful feature, but please don't make it possible to confuse the two, and please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Both oligarch and tyrant mistrust the people, and therefore deprive them of arms. --Aristotle - 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/
Re: CML2 design philosophy heads-up
David Woodhouse [EMAIL PROTECTED]: On one hand you have dependencies which are present to make life easier for Aunt Tillie, by refraining from confusing her with strange questions to which the answer is _probably_ 'no'. Like the question of whether she has an IDE controller on her MVME board. One the other hand, you have the dependencies present in the existing CML1 configuration, which are _absolute_ dependencies - which specify for example that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. These dependencies are there to prevent you from enabling combinations of options which are utterly meaningless, and usually won't even compile. There are no `advisory' dependencies in CML2. They're all absolute. What you call an `advisory' dependency would be simulated by having a policy symbol for Aunt Tillie mode and writing constraints like this: require AUNT_TILLIE implies FOO = BAR This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING policy symbols, as hooks for doing things like this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a No one who's seen it in action can say the phrase government help without either laughing or crying. - 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/
Background to the argument about CML2 design philosophy
the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is yes, sometimes is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is no will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset. So far, I have to say I'm disappointed in the quality of the debate. Almoist nobody seems to want to think about this tradeoff globally, as a systems design issue. Instead, I'm hearing a lot of reflexive chuntering that we have to do things a certain way because we've always done them a certain way, and who am I to even dare *think* about raising different possibilities? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a [The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, Advice to the Privileged Orders, 1792-93 - 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/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton [EMAIL PROTECTED]: One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. To satisfy some others, you might want to say Hey, these guys might want to *explicitly turn off* some of this stuff - so provide an option under Are you insane? which presents all the derived symbols and allows the hackers to manually turn stuff off. Interesting thought... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 - 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/
Re: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in Phila. Independent Gazetteer, August 20, 1789 - 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/
Brown-paper-bag bug in m68k, sparc, and sparc64 config files
This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it. This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time. --- arch/m68k/config.in 2001/05/19 21:36:57 1.1 +++ arch/m68k/config.in 2001/05/19 21:37:12 @@ -192,7 +192,7 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi dep_tristate ' SCSI CD-ROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI --- arch/sparc/config.in2001/05/19 21:34:54 1.1 +++ arch/sparc/config.in2001/05/19 21:35:21 @@ -162,7 +162,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi --- arch/sparc64/config.in 2001/05/19 21:37:33 1.1 +++ arch/sparc64/config.in 2001/05/19 21:37:45 @@ -146,7 +146,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Conservatism is the blind and fear-filled worship of dead radicals. - 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/
Brown-paper-bag bug in m68k, sparc, and sparc64 config files
This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it. This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time. --- arch/m68k/config.in 2001/05/19 21:36:57 1.1 +++ arch/m68k/config.in 2001/05/19 21:37:12 @@ -192,7 +192,7 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ $CONFIG_BLK_DEV_ST != n ]; then + if [ $CONFIG_CHR_DEV_ST != n ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi dep_tristate ' SCSI CD-ROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI --- arch/sparc/config.in2001/05/19 21:34:54 1.1 +++ arch/sparc/config.in2001/05/19 21:35:21 @@ -162,7 +162,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ $CONFIG_BLK_DEV_ST != n ]; then + if [ $CONFIG_CHR_DEV_ST != n ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi --- arch/sparc64/config.in 2001/05/19 21:37:33 1.1 +++ arch/sparc64/config.in 2001/05/19 21:37:45 @@ -146,7 +146,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ $CONFIG_BLK_DEV_ST != n ]; then + if [ $CONFIG_CHR_DEV_ST != n ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Conservatism is the blind and fear-filled worship of dead radicals. - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - 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/
Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > What I am trying to say is that if you can infer probable configuration > categories that are relevant then instead of automatically filling the other > areas in and blocking changing them without using vi you can put the other > options as a submenu. That guides the less expert user and also helps rather > than hinders the expert OK, that's useful input. Noted. There's a bit of a technical problem with the distinction between derivations (which are like macros) and question symbols (which can be suppressed or unsuppressed depending on their visibility predicate But perhaps I can think up a solution to that one over lunch. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > I hereby volunteer to maintain at least make oldconfig and make config, > and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire CML1 ruleset in parallel with the canonical CML2 one. That's the hard part. I've been keeping the CML2 ruleset synced with CML1 for a year now. It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. "Like chewing razor blades" is the simile that leaps to mind. (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Meissner <[EMAIL PROTECTED]>: > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After > all, all of us at one point in time were newbies in terms of configuring > kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford - 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/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > Right now, it's now a dropping back. You seem to take for granted that CML2 > and your python2 frontend to it are 2.5.0 material. I don't right now. Linus is free to change his mind. Perhaps he will. But the last word I heard from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe. That's the assumption I'm operating on. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 - 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/
Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > In my opinion, no configuration that is actually physically possible > is perverse. Noted. And a very pithy statement of the position. Thanks. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson - 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/
