Ladies and gentlemen,
I would find this pathetic, if it didn't make me so mad.
Making an end run around the system, are we, Eric?
Small wonder the message below didn't make it to linux-kernel:
suggestions would have been made that CML2 is DOA.
ESR's message to the kbuild list:
http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
The rest of the thread:
http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
For an open source "guru", Eric, you sure seem to like to turn to
cronyism and secret meetings when the going gets tough.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
On Fri, 15 Feb 2002, Jeff Garzik wrote:
> ESR's message to the kbuild list:
> http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
> The rest of the thread:
> http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
>
> For an open source "guru", Eric, you sure seem to like to turn to
> cronyism and secret meetings when the going gets tough.
This makes me wonder whether Eric works in a cathedral
or in an ivory tower ...
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
Jeff Garzik <[email protected]>:
> I would find this pathetic, if it didn't make me so mad.
> Making an end run around the system, are we, Eric?
No. I'm doing what Dirk Hohndel recommended I do during a phone call
that happened at his initiative, last Friday morning.
What "system" would you be referring to, anyway, Jeff? Is there some
reason a respected open-source developer like Dirk who has concerns
should not have a conversation with Linus to address problems he thinks
are significant? Is there some reason I should not have asked the kbuild
team members to give him appropriate background?
I don't understand what is upsetting you. Is there some rule that all
conversations with Linus must go through Jeff Garzik? If so, I was never
informed of it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:
> I don't understand what is upsetting you. Is there some rule that all
> conversations with Linus must go through Jeff Garzik? If so, I was never
> informed of it.
No, but at the least keeping Linux-Kernel in the loop would be
considered not just nice, but a somewhat more courteous method
than 'sending someone around to go see Linus' when your pet
project isn't getting the acceptance you hoped for.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:
> Jeff Garzik <[email protected]>:
> > I would find this pathetic, if it didn't make me so mad.
> > Making an end run around the system, are we, Eric?
>
> What "system" would you be referring to, anyway, Jeff? Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant? Is there some reason I should not have asked the kbuild
> team members to give him appropriate background?
Yeah, there is. The point of *open* source is that it is *open*, Eric.
Jeff, if I understand him correctly, is making the point that if a
system can't stand up to public scrutiny, trying to get it in by private
campaigning is lame, not the open source way, and a little bit sleazy.
The open source development model depends on peer review, you might go
back and read some of your many essays on the topic. Don't you take
commercial companies to task for doing exactly what you are doing?
Your actions are confusing, do your writings apply to other people but
not to you? If there is some misunderstanding about your actions,
please clear it up. If not, practice what you preach.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:
> What "system" would you be referring to, anyway, Jeff? Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant?
Is there some reason this isn't being discussed on l-k again? Lots of
people have concerns about the whole build system. Ignoring the whole
python debate, there's actual issues about the CML2 package.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
"Eric S. Raymond" wrote:
>
> Jeff Garzik <[email protected]>:
> > I would find this pathetic, if it didn't make me so mad.
> > Making an end run around the system, are we, Eric?
>
> No. I'm doing what Dirk Hohndel recommended I do during a phone call
> that happened at his initiative, last Friday morning.
>
> What "system" would you be referring to, anyway, Jeff? Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant? Is there some reason I should not have asked the kbuild
> team members to give him appropriate background?
>
> I don't understand what is upsetting you. Is there some rule that all
> conversations with Linus must go through Jeff Garzik? If so, I was never
> informed of it.
Eric,
What I see on linux-kernel is you writing long diatribes, and then
promptly ignoring feedback from kernel developers who would actually be
using your system. After months and months of being told that
Configure.help needed to be split up, you just continued to whine.
Linus finally sat down and did it himself. Back in December, Linus
talked about per-driver and/or per-subsystem metadata files, which would
contain (among other things) the config information. That seems like a
sane option to me, and other developers agreed. You ignored that too.
With regards to kbuild (not CML2), Keith publicly stated he didn't care
about 2.5.
I feel sorry about that you have troubled Dirk, without giving him all
the facts.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
On Fri, 15 Feb 2002, Rik van Riel wrote:
> On Fri, 15 Feb 2002, Jeff Garzik wrote:
>
> > ESR's message to the kbuild list:
> > http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
> > The rest of the thread:
> > http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
> >
> > For an open source "guru", Eric, you sure seem to like to turn to
> > cronyism and secret meetings when the going gets tough.
>
> This makes me wonder whether Eric works in a cathedral
> or in an ivory tower ...
Judging by usual Eric's intellectual erm... output the word you are looking
for is "outhouse".
Larry McVoy <[email protected]>:
> Yeah, there is. The point of *open* source is that it is *open*, Eric.
> Jeff, if I understand him correctly, is making the point that if a
> system can't stand up to public scrutiny, trying to get it in by private
> campaigning is lame, not the open source way, and a little bit sleazy.
So what "private campaigning" is going on here, exactly?
Dirk approached me because he was concerned that politics and poor
communication might be getting in the way of some valuable work. He
asked me to have the kbuild team fill him in on the background, and I
relayed that request. The kbuild team's discussion with Dirk is
taking place on a public mailing list.
I'm bewildered. What's the problem here?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Jeff Garzik <[email protected]>:
> What I see on linux-kernel is you writing long diatribes, and then
> promptly ignoring feedback from kernel developers who would actually be
> using your system. After months and months of being told that
> Configure.help needed to be split up, you just continued to whine.
I heard Linus say that he wanted Configure.help split up. I agreed to
do it, too, in CML2. But I thought I was not supposed to mess with existing
formats -- in fact, I was afraid to, because you and Al Viro beat me up
so hard about changing *nothing* before cutover. The CML1 code owns that
format, and I am not the CML1 maintainer. In fact mec specifically turned
me down when I volunteered for that job; he said he wanted me concentrating
on CML2.
Neither Linus nor anyone else ever said to me "Eric, it's your job to
make that change." When I asked for guidance, Linus blackholed my mail.
Was I supposed to be practicing telepathy, here?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Jeff Garzik <[email protected]> writes:
> For an open source "guru", Eric, you sure seem to like to turn to
> cronyism and secret meetings when the going gets tough.
Yeah, you should have heard him four years or so ago suggesting that
due to the ncurses license he would be able to deny Thomas Dickey
ownership of his own code when Thomas (who had been doing all
significant development on ncurses for a year or more) attempted to
make his own release of ncurses (4.1, as I recall).
Fortunately all parties agreed to the code being assigned to the FSF,
getting ESR out owning a critical-path library.
Mike.
Jeff Garzik <[email protected]> wrote:
> I would find this pathetic, if it didn't make me so mad.
> Making an end run around the system, are we, Eric?
>
> Small wonder the message below didn't make it to linux-kernel:
> suggestions would have been made that CML2 is DOA.
>
> ESR's message to the kbuild list:
> http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
> The rest of the thread:
> http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
>
> For an open source "guru", Eric, you sure seem to like to turn to
> cronyism and secret meetings when the going gets tough.
>From my distant and peonic vantage point,
I don't see what the big deal is; Eric's messages
look perfectly fine. Perhaps he should have cc'd linux-kernel,
but you could also argue that kbuild-devel was
exactly the right place to post discussions of
the kernel build system. Eric is at worst guilty of
a minor misstep. Don't pillory him; he really is simply
trying to do a good job.
Besides, it's not smart to insult a man who carries a gun :-)
- Dan
On Fri, 15 Feb 2002, Eric S. Raymond wrote:
> I heard Linus say that he wanted Configure.help split up. I agreed to
> do it, too, in CML2. But I thought I was not supposed to mess with existing
> formats -- in fact, I was afraid to, because you and Al Viro beat me up
> so hard about changing *nothing* before cutover. The CML1 code owns that
Ah, now we see the violence inherent in the system.
> format, and I am not the CML1 maintainer. In fact mec specifically turned
> me down when I volunteered for that job; he said he wanted me concentrating
> on CML2.
>
> Neither Linus nor anyone else ever said to me "Eric, it's your job to
> make that change." When I asked for guidance, Linus blackholed my mail.
Oh! Come and see the violence inherent in the system!
Help! Help! I'm being repressed!
> Was I supposed to be practicing telepathy, here?
Oh, what a dead giveaway. Did you hear that, did you hear that, eh?
That's what I'm on about - did you see him repressing me, you saw it,
didn't you?
Dennis^WEric, just one question: had it ever occured to you that
for a self-proclaimed "hacker of social systems" you are doing spectaculary
poor job?
Alexander Viro <[email protected]>:
> > Neither Linus nor anyone else ever said to me "Eric, it's your job to
> > make that change." When I asked for guidance, Linus blackholed my mail.
>
> Oh! Come and see the violence inherent in the system!
> Help! Help! I'm being repressed!
Your reply was pretty funny. Well, I laughed anyway.
But laughter won't make the chronic communications problems go away.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Dave Jones <[email protected]>:
> No, but at the least keeping Linux-Kernel in the loop would be
> considered not just nice, but a somewhat more courteous method
> than 'sending someone around to go see Linus' when your pet
> project isn't getting the acceptance you hoped for.
No sending around is involved. Dirk approached me, not the other
way around.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
In article <[email protected]> you wrote:
>
> But laughter won't make the chronic communications problems go away.
A "I don't like don't like <FOO> and won't apply it" is not a communications problem in general. When the person trying to submit <FOO> keeps submitting it without listening to suggestions or to reasons why it's not applied.... THEN there is a one sided communcation problem.
Not saying that's the case here, but it starts to appear to be so.
Arjan van de Ven <[email protected]>:
> A "I don't like don't like <FOO> and won't apply it" is not a communications problem in general. When the person trying to submit <FOO> keeps submitting it without listening to suggestions or to reasons why it's not applied.... THEN there is a one sided communcation problem.
>
> Not saying that's the case here, but it starts to appear to be so.
Arjan, I would dearly love to get useful feedback on why things like my
Configure.help patches weren't applied. It would be a delight like
water in the desert to *hear* some reasons!
But I think you know very well that the usual flow looks like this:
1. You throw a patch over the wall to Linus.
2. Either it shows up in the next release...
3. ...or you hear a vast and echoing silence.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 02:14:33PM -0500, Eric S. Raymond wrote:
> Arjan, I would dearly love to get useful feedback on why things like my
> Configure.help patches weren't applied. It would be a delight like
> water in the desert to *hear* some reasons!
>
> But I think you know very well that the usual flow looks like this:
>
> 1. You throw a patch over the wall to Linus.
>
> 2. Either it shows up in the next release...
>
> 3. ...or you hear a vast and echoing silence.
You're telling me Linus never mailed you about splitting up Configure.help ?
Arjan van de Ven <[email protected]>:
> > But I think you know very well that the usual flow looks like this:
> >
> > 1. You throw a patch over the wall to Linus.
> >
> > 2. Either it shows up in the next release...
> >
> > 3. ...or you hear a vast and echoing silence.
>
> You're telling me Linus never mailed you about splitting up Configure.help ?
That's right. The only time I ever saw Linus express an opinion on
this was in a post on lkml in which he said he didn't like the big
monolithic help file. It didn't seem especially directed to me; I am
not the CML1 maintainer.
But I took it as a suggestion for CML2. I told him I was willing to
do it after CML2 cutover, but was not sure he had considered the
ramifications for maintaining rulebase translations. To this request
for clarification and guidance, I received no reply.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 02:54:21PM -0500, Eric S. Raymond wrote:
> > You're telling me Linus never mailed you about splitting up Configure.help ?
> That's right. The only time I ever saw Linus express an opinion on
> this was in a post on lkml in which he said he didn't like the big
> monolithic help file. It didn't seem especially directed to me; I am
> not the CML1 maintainer.
I recall the threads you mention.
I also recall at least a half dozen regular contributors agreeing
that splitting up Configure.help was the way forward.
> But I took it as a suggestion for CML2. I told him I was willing to
> do it after CML2 cutover
This is something I never understood. CML1 has served us for
10 years or so, and suddenly its declared "unfixable".
"I'm not hacking that, I'll fix it in CML2" seemed to become
the attitude. End result ? Linus got pissed off with your
complaints of non-inclusion, and _fixed_ one of the CML1 problems
(Configure.help) And how long did it take ? ISTR it was around
an hour after his first mail was sent to you, me & Jeff.
1 hour. Versus the year you spent procrastinating about how
CML2 would fix it.
Sure CML2 fixes some bits that are not easily fixed in CML1,
but I wonder sometimes how much of it is/was fixable.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, Feb 15, 2002 at 02:54:21PM -0500, Eric S. Raymond wrote:
> Arjan van de Ven <[email protected]>:
> > > But I think you know very well that the usual flow looks like this:
> > >
> > > 1. You throw a patch over the wall to Linus.
> > >
> > > 2. Either it shows up in the next release...
> > >
> > > 3. ...or you hear a vast and echoing silence.
> >
> > You're telling me Linus never mailed you about splitting up Configure.help ?
>
> That's right.
Gimme a break. I read those posts, I repeatedly saw that people said to do
that, I don't remember if it was Linus or not, but it's not like he has the
only brain. The clearly expressed sentiment was to put the help next to the
source. You repeatedly came up with corner cases where that wouldn't work
and used that as an excuse to do nothing. Having just gone through the same
thing with Linus about BK locking, I can assure you that dredging up the
corner cases does not work, you might as well get to work and solve the
problem.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]>:
> Gimme a break. I read those posts, I repeatedly saw that people said to do
> that, I don't remember if it was Linus or not, but it's not like he has the
> only brain. The clearly expressed sentiment was to put the help next to the
> source. You repeatedly came up with corner cases where that wouldn't work
> and used that as an excuse to do nothing.
And one of those corner cases in fact came around and bit us on the ass.
If we had handled the transition the smooth way I wanted to, and was
prepared to, we'd still have a maintainable help database spanning 2.4
as well as 2.5. As it is, Linus blew my system into flinders and
obsoleted all my tools (I'm not talking CML2 itself now but the machinery I
wrote for tracking help changes).
As a result, I had to tell Marcelo I had no choice but to drop maintaining
the 2.4 help file. The divergence, and the damage, is probably not
recoverable.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Dave Jones <[email protected]>:
> This is something I never understood. CML1 has served us for
> 10 years or so, and suddenly its declared "unfixable".
Yes, and not by me. By the people who wrote it.
> "I'm not hacking that, I'll fix it in CML2" seemed to become
> the attitude. End result ? Linus got pissed off with your
> complaints of non-inclusion, and _fixed_ one of the CML1 problems
> (Configure.help) And how long did it take ? ISTR it was around
> an hour after his first mail was sent to you, me & Jeff.
> 1 hour. Versus the year you spent procrastinating about how
> CML2 would fix it.
>
> Sure CML2 fixes some bits that are not easily fixed in CML1,
> but I wonder sometimes how much of it is/was fixable.
The first thing I heard, from mec two years ago, was "the CML1 code
base is not salvageable". This was then and is now the unanimous opinion of
the kbuild team. Not just mine; in fact, they concluded it before
I entered the picture.
I have seen nothing since to make me change that opinion.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 03:39:53PM -0500, Eric S. Raymond wrote:
> As a result, I had to tell Marcelo I had no choice but to drop maintaining
> the 2.4 help file. The divergence, and the damage, is probably not
> recoverable.
find . -name Config.help -exec cat {} >Configure.help \;
Ok, they'll perhaps not be in the same order as your original
working set, but that issue goes away when you split your
set up with the tools Linus gave you, and regenerate.
Maintaining is hard, lets go shopping.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> Sure CML2 fixes some bits that are not easily fixed in CML1,
> but I wonder sometimes how much of it is/was fixable.
Pretty much all of it. I wrote a proof of concept parser that can deduce
the set of rules that must be enforced and what must be changed when you
hit an option
On Friday 15 February 2002 01:55 pm, Eric S. Raymond wrote:
> Alexander Viro <[email protected]>:
> > > Neither Linus nor anyone else ever said to me "Eric, it's your job to
> > > make that change." When I asked for guidance, Linus blackholed my
> > > mail.
> >
> > Oh! Come and see the violence inherent in the system!
> > Help! Help! I'm being repressed!
>
> Your reply was pretty funny. Well, I laughed anyway.
>
> But laughter won't make the chronic communications problems go away.
Speaking as a proud member of Al Viro's killfile (from one work account and
one home accounts, each time for lkml postings he wasn't cc:'d on, which
somehow set him off anyway), I really doubt he perceives lack of
communication as much of a problem. More of a solution. :)
Seeing a conspiracy in the existence of any posts to public mailing lists
other than linux-kernel is, however, the kind of paranoia for which
medication is prescribed. (Would the reactionary front have preferred Eric
email the various developers directly in a big CC:, instead of a posting to a
PUBLIC LIST, which apparently Jeff DID find and highlighted? I'd say the
"help help this is being repressed" came at the start of this thread, not
when Eric jumped in.)
And when did talking to Linus directly (in email or on the phone) become
something that Linus needed to be protected from? (Look out guys! Some
people are thinking of TALKING DIRECTLY TO LINUS! Without consulting us
first! They must be found and stopped!)
And here I thought Linus was very good at saying no, in a multitude of
contexts...
Rob
Dave Jones <[email protected]>:
> > As a result, I had to tell Marcelo I had no choice but to drop maintaining
> > the 2.4 help file. The divergence, and the damage, is probably not
> > recoverable.
>
> find . -name Config.help -exec cat {} >Configure.help \;
Back-seat drivers. Answers for everything, understanding of nothing.
Sorry, it's not *nearly* that simple. For one thing, one of the fourteen
billion requirements I've had dropped on me is that Marcelo doesn't want
any symbols in his help file that aren't actually in the 2.4 rulebase.
So I'd have to generate a custom version for him. I used to have the
machinery to do that by parsing magic comments in my master file.
Until Linus blew it apart.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Alan Cox <[email protected]>:
> > Sure CML2 fixes some bits that are not easily fixed in CML1,
> > but I wonder sometimes how much of it is/was fixable.
>
> Pretty much all of it. I wrote a proof of concept parser that can deduce
> the set of rules that must be enforced and what must be changed when you
> hit an option
Alan. It didn't work. It couldn't have -- among other things, the old
language can't tell visibility from implication.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> > Pretty much all of it. I wrote a proof of concept parser that can deduce
> > the set of rules that must be enforced and what must be changed when you
> > hit an option
>
> Alan. It didn't work. It couldn't have -- among other things, the old
> language can't tell visibility from implication.
The prototype generates a very convincing table set, and the tables generate
very convincing graphs. The information to work out what option needs another
as I've said for months
On Fri, Feb 15, 2002 at 03:58:17PM -0500, Eric S. Raymond wrote:
> Back-seat drivers. Answers for everything, understanding of nothing.
*plonk*
> Sorry, it's not *nearly* that simple. For one thing, one of the fourteen
> billion requirements I've had dropped on me is that Marcelo doesn't want
> any symbols in his help file that aren't actually in the 2.4 rulebase.
As you obviously completely ignored my previous point, I'll reiterate it.
1. You run Linus' split-into-config.in script on a 2.4 tree.
2. You add whatever Config.ins have been updated to the 2.4 config.ins
3. You regenerate with the find example I showed in the other mail.
There. 2.4 Configure.help up to date with latest symbols, but
containing none of the 2.5 ones.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, 2002-02-15 at 15:38, Dave Jones wrote:
> This is something I never understood. CML1 has served us for
> 10 years or so, and suddenly its declared "unfixable".
> "I'm not hacking that, I'll fix it in CML2" seemed to become
> the attitude. End result ? Linus got pissed off with your
> complaints of non-inclusion, and _fixed_ one of the CML1 problems
> (Configure.help) And how long did it take ? ISTR it was around
> an hour after his first mail was sent to you, me & Jeff.
> 1 hour. Versus the year you spent procrastinating about how
> CML2 would fix it.
Amen. This whole "CML1 vs CML2" thing is silly. We don't see other
"maintainers" refusing to touch code, having no relation to code, and
then coming out of no-where and offering some external solution for the
perceived problem.
If you _develop_ kernel code and see a problem with the configure
system, then fix the problems. As Linus says, let stuff evolve.
> Sure CML2 fixes some bits that are not easily fixed in CML1,
> but I wonder sometimes how much of it is/was fixable.
Agreed, but CML2 has a whole bunch of new "features" too which will be
shoved down our throats!!
Robert Love
Eric S. Raymond writes:
> So I'd have to generate a custom version for him. I used to have the
> machinery to do that by parsing magic comments in my master file.
> Until Linus blew it apart.
Repeat after me: Linus is a bastard. Linus doesn't care.
Everyone knows this. Even Linus admits he's a bastard. We all have to
live with changes. It's frustrating when some code you're maintaining
code for different kernel trees and you can't share a common master
due to API changes. But Linus doesn't care. This is the price of doing
business here. Everyone knows that. And (almost) everyone keeps coming
back for more punishment. People live with the system.
So, can we please drop this thread? You're frustrated. Fine. You've
had your chance to vent. OK. Everybody needs to do that from time to
time. But move on. Don't keep flogging this dead horse. You're
cutting into the bone, now.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Alan Cox <[email protected]>:
> The prototype generates a very convincing table set, and the tables generate
> very convincing graphs. The information to work out what option needs another
> as I've said for months
I've *solved* this problem. I understand the constraints. I know
exactly what you will have to do to get the rest of the way, *because
I did it*.
I have built not just a "proof of concept" but a working
implementation so robust that it is in production use by three
different projects. And a substantial number of kernel developers are
using it now and reporting it good.
The good thing about working with developers like you and Dave Jones
and many of the other loonies on this list is that you are fucking
brilliant. The bad thing is that because you're fucking brilliant,
you're often also ungodly arrogant about second-guessing other
peoples' work -- you think your snap judgment or "proof of concept" is
somehow equivalent to two years of design, coding and testing by
someone who has been concentrating on the problem.
News bulletin: IT'S NOT.
Alan, don't talk to me about "proof of concept". Tell me about a
production-quality system, proven in use by people like Embedsys,
Webmachines, and the Compache project. Tell me you can duplicate what
CML2 does successfully before you run around implying my design
assumptions are full of crap.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Richard Gooch <[email protected]>:
> Repeat after me: Linus is a bastard. Linus doesn't care.
Fine. We all know Linus is a bastard.
If that's so, then why are the likes of Jeff Garzik and Al Viro
spending so much effort trying to make *me* into the bad guy?
Time for somebody to up Jeff's Thorazine dosage...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
You're not going to get sympathy from this list for having your work "blown
apart" by Linus. Fix the problems that are holding things up or give up on
it. The current system, CML1, does function so you have to accept you're
pushing CML2 up a hill.
} So I'd have to generate a custom version for him. I used to have the
} machinery to do that by parsing magic comments in my master file.
} Until Linus blew it apart.
On Fri, 2002-02-15 at 15:39, Eric S. Raymond wrote:
> As a result, I had to tell Marcelo I had no choice but to drop maintaining
> the 2.4 help file. The divergence, and the damage, is probably not
> recoverable.
Divergence and damage to a configure help file ?
As someone who professes to be well-versed in social systems and their
associated mechanics, I am sure you understand the notions of social
contracts and the like. Thus, if we, as the developers who actually
look at the Config.help, drop the changes then that is our problem. And
if we don't care, then there must be nothing to care about.
If Marcelo and Linus are not begging for Configure.help updates (like I
beg for SCSI layer rewrites) then there is a reason.
Robert Love
> > The prototype generates a very convincing table set, and the tables generate
> > very convincing graphs. The information to work out what option needs another
> > as I've said for months
>
> I've *solved* this problem. I understand the constraints. I know
> exactly what you will have to do to get the rest of the way, *because
> I did it*.
No you've replaced the system with one thats much harder to understand and
forces new tools on people. The *interesting* problem to solve is keeping
the existing infrastructure there and getting the same kind of results.
Since the information is there in CML1 to generate the list of constraints
for any given option, its a reasonable assertion that the entire CML2
language rewrite is self indulgence from a self confessed language invention
freak.
Alan
On Fri, Feb 15, 2002 at 04:50:29PM -0500, Eric S. Raymond wrote:
> If that's so, then why are the likes of Jeff Garzik and Al Viro
> spending so much effort trying to make *me* into the bad guy?
'the bad guy' probably isn't the right choice of words.
The point being made is that you constantly refuse to listen.
You ask for an opinion, and when something comes back that isn't
what you expect, you run off and write something completely
different just to appease some fabled Aunt Tilley, then come
back and say "Ok, how about now?".
CML2 seems to have all these wonderous features to make end-users
happy. In writing these, you've shifted target audience from
kernel _developers_ to kernel _users_. Concerns from developers
were constantly ignored in favour of adding extra candy.
And you wonder why developers don't want to read about CML2 any more?
You know, for all its glorious features, I'd not be surprised
to see mconfig or some other 'improved CML1' end up in 2.6
rather than CML2.
> Time for somebody to up Jeff's Thorazine dosage...
Increased dosages of something all around wouldn't go amiss I think.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, Feb 15, 2002 at 03:09:25PM -0700, Richard Gooch wrote:
> Eric S. Raymond writes:
> > So I'd have to generate a custom version for him. I used to have the
> > machinery to do that by parsing magic comments in my master file.
> > Until Linus blew it apart.
>
> Repeat after me: Linus is a bastard. Linus doesn't care.
And he owes me $5 which he won't pay
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
On Fri, Feb 15, 2002 at 05:08:42PM -0500, Robert Love wrote:
> > Sure CML2 fixes some bits that are not easily fixed in CML1,
> > but I wonder sometimes how much of it is/was fixable.
> Agreed, but CML2 has a whole bunch of new "features" too which will be
> shoved down our throats!!
Increased functionality I don't have a problem with, as long
as other more important things are addressed. And for that matter,
Linus has said to Eric "I don't care, take this out of the
kernel completely leaving just oldconfig'.
It might just be the sanest choice, and leave all this discussion
in userland.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> If that's so, then why are the likes of Jeff Garzik and Al Viro
> spending so much effort trying to make *me* into the bad guy?
I don't think they are. They are just watching you do it yourself
> Time for somebody to up Jeff's Thorazine dosage...
See...
Dave Jones <[email protected]>:
> As you obviously completely ignored my previous point, I'll reiterate it.
>
> 1. You run Linus' split-into-config.in script on a 2.4 tree.
> 2. You add whatever Config.ins have been updated to the 2.4 config.ins
> 3. You regenerate with the find example I showed in the other mail.
>
> There. 2.4 Configure.help up to date with latest symbols, but
> containing none of the 2.5 ones.
And you've completely ignored the real problem...which is when I get
a text change for one tree, *how do I automatically propagate it to
the other*? How do I *tell* that it ought to be propagated?
It's not sufficient to develop a one-shot conversion procedure. What
I came up with had to allow me to continue generating correct help
files for all trees under the assumption that text changes for 2.4
could come in against the 2.5 copy of the help entry, or vice-versa --
bearing in mind that some symbols have divergent text and that's correct.
Solutions that involve me doing an arbitrary and increasing amount of
hand-hacking on every release are right out.
If you think this problem through, I'm sure you'll come up with a
design very similar to what I actually built. Which, by Linus's
choice, got irrecoverably nuked.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Alan Cox <[email protected]>:
> Since the information is there in CML1 to generate the list of constraints
> for any given option,
False assumption...
> its a reasonable assertion that the entire CML2
> language rewrite is self indulgence from a self confessed language invention
> freak.
leading to a false result.
If you want to refute me, build it yourself. You'll get a valuable learning
experience. At the end of it, I'll have earned your apology. Not that I
expect to get it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 04:50:29PM -0500, Eric S. Raymond wrote:
> Richard Gooch <[email protected]>:
> > Repeat after me: Linus is a bastard. Linus doesn't care.
>
> Fine. We all know Linus is a bastard.
>
> If that's so, then why are the likes of Jeff Garzik and Al Viro
> spending so much effort trying to make *me* into the bad guy?
Perhaps they don't like the results of your efforts and they resent what
they perceive to be end runs around the normal process of getting changes
accepted. As well they should. Your attempt to avoid peer review is
disgusting, it's the worst of what happens in closed source shops when
marketing forces the wrong answer in over the objections of the people
who have to live with it. Yuck.
If you really want to contribute, what you'll do is improve the existing
system. Screaming that it can't be done just means you aren't a kernel
programmer. What kernel programmers do is the hard ugly work it takes to
make things work smoothly. Look at any device driver - just a handfull
of simple interfaces: open,close,read,write,ioctl (ok that last one is
far from simple). Now go look at the code implementing those interfaces,
it's frequently a huge effort to make some recalcitrant device behave.
But that's what kernel programmers do. They take a mess and present
a clean, well working system. No one said it was easy. If you are a
kernel programmer, you can take CML1 and make it work, for a reasonable
definition of "work". If you can't, you're far better off to admit
you're in over your head and give it up. Harping on CML2 as the better
answer isn't going to work. Neither is telling people they don't get it,
when those same people have done 10,000 times more work on the kernel
than you'll ever do.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> Alan Cox <[email protected]>:
> > Since the information is there in CML1 to generate the list of constraints
> > for any given option,
>
> False assumption...
Do you have anything more constructive that "doesnt" to say
> If you want to refute me, build it yourself. You'll get a valuable learning
> experience. At the end of it, I'll have earned your apology. Not that I
> expect to get it.
Been there, done that, got the pretty graphs. Possibly the next step is to
redo the work into mconfig which already does pretty much anything we need
with the existing config files parsed using a real 100% genuine yacc grammar
Dave Jones <[email protected]>:
> Increased functionality I don't have a problem with, as long
> as other more important things are addressed. And for that matter,
> Linus has said to Eric "I don't care, take this out of the
> kernel completely leaving just oldconfig'.
>
> It might just be the sanest choice, and leave all this discussion
> in userland.
CML2 can live in userland. It already does; three other projects use it.
The kernel rulebase cannot. The real issue here is whether the CML1
language carries sufficient information to support things like
side-effect deduction. And the answer is "no".
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Fri, Feb 15, 2002 at 05:04:59PM -0500, Eric S. Raymond wrote:
> And you've completely ignored the real problem...which is when I get
> a text change for one tree, *how do I automatically propagate it to
> the other*? How do I *tell* that it ought to be propagated?
Depends on the context of the change.
In a majority of cases the answer is RTFC.
If this is too much effort, rethink your outlook on whats
involved as 'maintainer' of something like the Config.help's.
This is precisely the reason that splitting them was the best
thing that could have happened. They are now maintained by
the people who actually *know* whats involved, so you don't have to.
> Solutions that involve me doing an arbitrary and increasing amount of
> hand-hacking on every release are right out.
Reading diffs and finding out why things changed, and following
conversations on Linux-kernel are the only way you'll know if
something is relevant in other trees. If you've a robot that can
do this, I'm all ears, as it could save me hours each day.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Friday 15 February 2002 04:46 pm, Eric S. Raymond wrote:
> Alan, don't talk to me about "proof of concept". Tell me about a
> production-quality system, proven in use by people like Embedsys,
> Webmachines, and the Compache project. Tell me you can duplicate what
> CML2 does successfully before you run around implying my design
> assumptions are full of crap.
Eric, step back a sec. Deep breaths.
Nobody ever said CML1 had to be able to serve projects other than
linux-kernel. The fact CML2 can is nice, but irrelevant. That argument goes
nowhere.
The amount of time you've invested in your code isn't particularly
interesting to anybody but you, except as an unreliable yardstick of how long
it might take to duplicate things. The "genius from mars" technique might be
able to come up with an even better way in a week, you never know. (Even a
really hard problem space can be elegantly solved out of left field. It's
not likely, but you never know.)
The other side of the argument is that a proof of concept is not the same
thing as actually solving the problem. You have working code. Several other
people have unimplemented theoretical proposals, tests, and prototypes that
don't actually do anything useful as of yet. That's the main argument you
should probably be making.
If people want to prove Eric wrong, then make CML1 work well. If you believe
it's not as hard a problem as he says it is, then by all means prove him
wrong. Arguing about how hard the problem really would be to solve, without
actually solving it... Why?
Rob
Dave Jones <[email protected]>:
> The point being made is that you constantly refuse to listen.
> You ask for an opinion, and when something comes back that isn't
> what you expect, you run off and write something completely
> different just to appease some fabled Aunt Tilley, then come
> back and say "Ok, how about now?".
I honestly don't undestand how this myth got started, Dave.
>From my point of view, I have been busting my ass trying to *extract*
requirements from Linus and other people with a stake. What guidance
I get is vague and contradictory. My proposals to address it get ignored.
Everything I do right gets written off and teensy side issues get
inflated into monsters.
It's utterly maddening to hear people accuse me of not listening when
I spend so damn much effort trying to do what they want for so little
reward...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Larry McVoy <[email protected]>:
> Perhaps they don't like the results of your efforts and they resent what
> they perceive to be end runs around the normal process of getting changes
> accepted. As well they should. Your attempt to avoid peer review is
^^^^^^^^^^^^^^^^^
> disgusting, it's the worst of what happens in closed source shops when
> marketing forces the wrong answer in over the objections of the people
> who have to live with it. Yuck.
I've "avoided peer review" really effectively, yeah. Unanimous support
from the kbuild team. Three other projects using the software. Dozens
of beta testers. Nope, no review at all there. Ain't I clever?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> The kernel rulebase cannot. The real issue here is whether the CML1
> language carries sufficient information to support things like
> side-effect deduction. And the answer is "no".
Thats an opinion not an answer. What doesn't it contain ?
On Fri, 15 Feb 2002, Larry McVoy wrote:
> If you really want to contribute, what you'll do is improve the existing
> system. Screaming that it can't be done just means you aren't a kernel
> programmer. What kernel programmers do is the hard ugly work it takes to
> make things work smoothly. Look at any device driver - just a handfull
> of simple interfaces: open,close,read,write,ioctl (ok that last one is
> far from simple). Now go look at the code implementing those interfaces,
> it's frequently a huge effort to make some recalcitrant device behave.
>
> But that's what kernel programmers do. They take a mess and present
> a clean, well working system. No one said it was easy. If you are a
> kernel programmer, you can take CML1 and make it work, for a reasonable
> definition of "work". If you can't, you're far better off to admit
> you're in over your head and give it up. Harping on CML2 as the better
> answer isn't going to work. Neither is telling people they don't get it,
> when those same people have done 10,000 times more work on the kernel
> than you'll ever do.
(cc: list killed, I assume all are subscribed to l-k)
Preface: I have no plan of kbuild and kernel configuration, so take this
with a grain of salt. But maybe it gives me the chance to calm all this
because I'm not biased towards either side.
Are you telling that kernel programmers don't rewrite code from scratch?
Is that a correct interpretation of "improve the existing system"? Note
that "it can't be done" can also imply "cannot reasonable be done".
If that's not what you mean, stop reading this mail, drop a line to
clarify this and forget this piece of mail. If it _is_ what you mean,
then with all due respect, why cannot kernel programmers rewrite a
subsystem (even if it interfaces with the whole world of kernel
configurations) from scratch?
Eric has done it, without being of kernel hacker temple's fame.
Whether he doesn't listen to other developers, I cannot tell, I got my
/fetchmail/ issues resolved. Still, I share the opinion that the kernel
build stuff is mainly for developers (and if it cuts down turnaround
times, it well deserves a try), and if -- as a side effect -- it's good
for the user, so be it, and if it's clear and self documenting, that's
nothing a developer would reject. Resurrecting this IMHO dead thread
around Mrs. Tillie won't bring any good. (Although Aunt Tillie should
really get her kernel as .deb or .rpm.)
AFAICS, Eric has gone lengths to get a competitive kernel configuration
system working well enough for production use, minor issues seem to
remain, like split Configure.help. I can easily understand no-one is
throwing this work away. If he's convinced the system is more consistent
and robust in itself, that's good -- but all this advocacy seems to be
torn down to some (personal) vendetta. Linux does not deserve that.
What I'm missing in this thread are facts. The point "communications
problem" has been raised. It seems to me as though the two opposing
parties (pro and con CML2) were not clear about what they expect from
the other party. If something has gone on behind the scenes, well, I
will have missed it...
I'm really hoping that this issue can get resolved in one way or
another, my personal opinion is that one single config stuff parser is
the goal, be it mconfig or be it CML2.
On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:
> Solutions that involve me doing an arbitrary and increasing amount of
> hand-hacking on every release are right out.
Um, Eric? Isn't that what being a maintainer basically means?
Okay, Linus's changes killed backwards compatability with 2.4. (He does
that. That's what 2.5 is for. It would be nice if less of it happened in
the stable series, but... :)
A maintainer is basically there to serve Linus (the project's undisputed
architect), who periodically makes the architectural decision to break
backwards compatability on some front.
You wanted to remain 2.4 help file maintainer as well as 2.5, and Linus did
not address this concern (for whatever reason: Linus blackholing email as a
way of disagreeing with it led to a lot of miscommunications like this one.)
Fine. Water under the bridge. Linus made an architectural decision, and it
has been implemented. If it means you can't maintain 2.4 anymore, the sane
move is to drop 2.4 (which you did) and move on.
That is why this is a dead issue, and bringing it up again doesn't serve as
much purpose as you think it does. (If you want to highlight the
blackhole-related miscommunication, fine. But even implying Linus's
architectural decision was wrong carries no weight with your audience.)
> If you think this problem through, I'm sure you'll come up with a
> design very similar to what I actually built. Which, by Linus's
> choice, got irrecoverably nuked.
Tough.
Eric, I like you and I still don't agree with you on this one.
First of all, the help files really are largely orthogonal to CML2. They
could be written in gzipped ebcdic. Make a filter, read them, move on. You
are pointelessly wasting brownie points on a dead side issue.
Secondly, please define the problem space you're going after. (I think that
the main objection people have to this tool, they don't agree with the
definition of the problem you're trying to solve.)
If you want CML2 is to be the best configure tool for the 2.5 (and later)
kernel series, fine. Then FOCUS ON THAT PROBLEM.
Overhead to deal with 2.4 is bloat. Flexibility for projects outside of the
kernel itself is a side issue. Aunt Tillie is NOT the initial target
audience. Usage to configure debian userspace or some such is completely
tangential. All of the above may be fun, but they do not serve to advance
the primary objective, and bringing them up does not help make a case for
CML2.
Back up a bit. What would be the most minimal, stripped-down version of CML2
you could write? No eye candy, no complications, no autoconfigurator, no
tree view, no frozen symbols. Just solving the core problem of configuring
2.5 in a more flexible and less buggy way than CML1, with the three
interfaces (oldconfig, menuconfig, xconfig) we've got now.
Think about that for a while. Try to get THAT into the kernel. THEN worry
about building on top of that.
Remember: Linus likes small patches. (CONCEPTUALLY small if possible, not
just lines of code...)
Rob
On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> Are you telling that kernel programmers don't rewrite code from scratch?
> Is that a correct interpretation of "improve the existing system"? Note
> that "it can't be done" can also imply "cannot reasonable be done".
> Eric has done it, without being of kernel hacker temple's fame.
The kernel hacker approach: Gradual change toward a predefined goal.
The Eric approach: Rip out existing, replace with new.
If Al Viro can rewrite the guts of the VFS without hardly anyone
noticing any disturbance, and the configuration system can't be
done this way, something is amiss.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> Are you telling that kernel programmers don't rewrite code from scratch?
> Is that a correct interpretation of "improve the existing system"? Note
> that "it can't be done" can also imply "cannot reasonable be done".
>
> If that's not what you mean, stop reading this mail, drop a line to
> clarify this and forget this piece of mail.
That's not what I mean. But it's worthwhile to note that almost all
"rewrite from scratch" projects really translate into "I'm unwilling to
learn what the last guy did, and I'm smarter, so I'm going to do what
I want to do". And that is not what kernel programmers do. They would
love to be able to do that but it's very rare that doing so makes sense.
In reality, the guy who came before you wasn't an idiot. Maybe s/he
didn't do the best job possible, but the fact that the code is there and
works implies some level of understanding. Real programmers make their
work fit *seamlessly* with the work of the people who came before them.
It's egoless programming, you are striving to make things fit so well
that noone can see where person A stopped and person B started.
In Eric's case, it would have been far better if he had done some work
to make CML1 work better. It simply isn't broken enough to justify
throwing it out. And it's not at all clear to me, at least, that the
CML2 stuff is any less broken, it's just broken in different ways.
Unless Eric can make a system that is widely viewed as better overall
than CML1, making one that is better in some ways but worse or just as
bad in others, well, that's a big waste of time.
At Sun, we had a rule that a major change was automatically disallowed
unless it showed a factor of 2 improvement in some important way while
holding the other variables constant. I don't think CML2 would pass
that test. Aunt Tillie's opinion doesn't count.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 15 Feb 2002, Eric S. Raymond wrote:
> Richard Gooch <[email protected]>:
> > Repeat after me: Linus is a bastard. Linus doesn't care.
>
> Fine. We all know Linus is a bastard.
>
> If that's so, then why are the likes of Jeff Garzik and Al Viro
> spending so much effort trying to make *me* into the bad guy?
I can't speak for Jeff. Compared to me Linus is downright nice,
kind and touchy-feely guy. I'm not. I don't like manipulative
arseholes. I _despise_ inept manipulative arseholes and I really
can't stand demagogy - what with a massive overdose of that in
school years (Soviet Union, early 80s - 'nuff said).
Your habit of claiming completely unsubstantiated credentials also
doesn't help. Let me spell it out - your pseudo-phylosophical
essays are handwaving at best and deliberate dishonesty at worst.
If you expect respect for them - you are looking in the wrong
place. You don't understand how kernel development works - that
much had been made obvious for everyone by the last couple of months.
And yet you don't hesitate to plug holes in your proposals with empty
preaching ex cathedra and massive demagogy.
I had seen such guys in Uni. Usually they taught Marxism-Leninism,
History of Party, Philosophy, etc. Nobody with a shred of clue and
self-respect had touched them with a ten-feet pole. Excuse me for
being not too happy to see that type again.
by the way folks, unless Eric is plain lying to us the 'private flamewar'
that Linus has with someone that prompted him to splitup the config.help
stuff was not with Eric.
David Lang
On Sat, 16 Feb 2002, Dave Jones wrote:
> Date: Sat, 16 Feb 2002 00:29:59 +0100
> From: Dave Jones <[email protected]>
> To: [email protected]
> Subject: Re: Disgusted with kbuild developers
>
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> > Eric has done it, without being of kernel hacker temple's fame.
>
> The kernel hacker approach: Gradual change toward a predefined goal.
> The Eric approach: Rip out existing, replace with new.
>
> If Al Viro can rewrite the guts of the VFS without hardly anyone
> noticing any disturbance, and the configuration system can't be
> done this way, something is amiss.
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
> -
> 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/
>
I wasn't at the kernel summit meeting, but my undersanding from the
'press' reports was that it was the CML1 guys who said they wanted to
throw it out and start from scratch. I don't know what role Eric had in
the discussion, but it sure didn't sound like it was him alone prompting
the change.
David Lang
On Fri, 15 Feb 2002, Larry McVoy wrote:
> Date: Fri, 15 Feb 2002 15:36:36 -0800
> From: Larry McVoy <[email protected]>
> To: [email protected]
> Subject: Re: Disgusted with kbuild developers
>
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> >
> > If that's not what you mean, stop reading this mail, drop a line to
> > clarify this and forget this piece of mail.
>
> That's not what I mean. But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do". And that is not what kernel programmers do. They would
> love to be able to do that but it's very rare that doing so makes sense.
>
> In reality, the guy who came before you wasn't an idiot. Maybe s/he
> didn't do the best job possible, but the fact that the code is there and
> works implies some level of understanding. Real programmers make their
> work fit *seamlessly* with the work of the people who came before them.
> It's egoless programming, you are striving to make things fit so well
> that noone can see where person A stopped and person B started.
>
> In Eric's case, it would have been far better if he had done some work
> to make CML1 work better. It simply isn't broken enough to justify
> throwing it out. And it's not at all clear to me, at least, that the
> CML2 stuff is any less broken, it's just broken in different ways.
> Unless Eric can make a system that is widely viewed as better overall
> than CML1, making one that is better in some ways but worse or just as
> bad in others, well, that's a big waste of time.
>
> At Sun, we had a rule that a major change was automatically disallowed
> unless it showed a factor of 2 improvement in some important way while
> holding the other variables constant. I don't think CML2 would pass
> that test. Aunt Tillie's opinion doesn't count.
> --
> ---
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> -
> 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/
>
Larry McVoy wrote:
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
>
>>Are you telling that kernel programmers don't rewrite code from scratch?
>>Is that a correct interpretation of "improve the existing system"? Note
>>that "it can't be done" can also imply "cannot reasonable be done".
>>
>>If that's not what you mean, stop reading this mail, drop a line to
>>clarify this and forget this piece of mail.
>>
>
> That's not what I mean. But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do". And that is not what kernel programmers do. They would
> love to be able to do that but it's very rare that doing so makes sense.
I have to call bullshit on this one! :)
The kernel is always getting some module replaced by some other
module. Everything from the VM to the recent ALSA merge that
will kill OSS. This is not to claim it's always a good thing,
just that you can't claim this is not what kernel programmers do...
Hell, we gotta be some of the most egotistical folks around,
it's what keeps us going!
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
On Fri, 15 Feb 2002, Eric S. Raymond wrote:
> Dave Jones <[email protected]>:
> > The point being made is that you constantly refuse to listen.
> > You ask for an opinion, and when something comes back that isn't
> > what you expect, you run off and write something completely
> > different just to appease some fabled Aunt Tilley, then come
> > back and say "Ok, how about now?".
>
> I honestly don't undestand how this myth got started, Dave.
>
> >From my point of view, I have been busting my ass trying to *extract*
> requirements from Linus and other people with a stake. What guidance
> I get is vague and contradictory. My proposals to address it get ignored.
> Everything I do right gets written off and teensy side issues get
> inflated into monsters.
>
> It's utterly maddening to hear people accuse me of not listening when
> I spend so damn much effort trying to do what they want for so little
> reward...
Eric....
Again... Just like I said to you in private email...
Show us that you're able to write a 1 for 1 functional correspondance
between CML1 and CML2 and propose that for inclusion into 2.5. This will
already have the advantage of using a common engine to parse the config
language regardless of the frontend used, along with the readability and
compactness of CML2. This should not cause a too big cultural change.
Wait for a month or two while developers get used to it. Then and only then
could you start discussion about advanced CML2 possibilities and features.
REmember that Linux development only works like a car that you propose
individual parts individually and let people comment on them. Providing the
whole car already assembled with a "turn key" package simply doesn't work
with most car hackers.
As a bonus to further stimulate acceptance of CML2, make it work with the
tools that most people already have i.e. Python 1.5.
Nicolas
> 'press' reports was that it was the CML1 guys who said they wanted to
> throw it out and start from scratch. I don't know what role Eric had in
> the discussion, but it sure didn't sound like it was him alone prompting
> the change.
I was at the summit but I guess I missed any real discussion on it, other
than the out of meeting sequence with Linus basically yelling at Eric
over some CML2 stuff.
I still hold the opinion the CML1 declarations are sufficient, and that
mconfig is more than enough to do what we need, possibly coupled with
some automatic rule validation stuff.
Michael Chastain fixed the nasty parsing mess in 1998
Here's an idea Al: Put up, or shut up. Where's your code to replace CML1
with? I like Eric's system, and find it's MUCH more useful in a production
environment than CML1 was. Where's your replacement idea?
Scott
----- Original Message -----
From: "Alexander Viro" <[email protected]>
To: "Eric S. Raymond" <[email protected]>
Cc: "Richard Gooch" <[email protected]>; "Dave Jones" <[email protected]>;
"Larry McVoy" <[email protected]>; "Arjan van de Ven"
<[email protected]>; <[email protected]>
Sent: Friday, February 15, 2002 5:37 PM
Subject: Re: Disgusted with kbuild developers
>
>
> On Fri, 15 Feb 2002, Eric S. Raymond wrote:
>
> > Richard Gooch <[email protected]>:
> > > Repeat after me: Linus is a bastard. Linus doesn't care.
> >
> > Fine. We all know Linus is a bastard.
> >
> > If that's so, then why are the likes of Jeff Garzik and Al Viro
> > spending so much effort trying to make *me* into the bad guy?
>
> I can't speak for Jeff. Compared to me Linus is downright nice,
> kind and touchy-feely guy. I'm not. I don't like manipulative
> arseholes. I _despise_ inept manipulative arseholes and I really
> can't stand demagogy - what with a massive overdose of that in
> school years (Soviet Union, early 80s - 'nuff said).
>
> Your habit of claiming completely unsubstantiated credentials also
> doesn't help. Let me spell it out - your pseudo-phylosophical
> essays are handwaving at best and deliberate dishonesty at worst.
> If you expect respect for them - you are looking in the wrong
> place. You don't understand how kernel development works - that
> much had been made obvious for everyone by the last couple of months.
> And yet you don't hesitate to plug holes in your proposals with empty
> preaching ex cathedra and massive demagogy.
>
> I had seen such guys in Uni. Usually they taught Marxism-Leninism,
> History of Party, Philosophy, etc. Nobody with a shred of clue and
> self-respect had touched them with a ten-feet pole. Excuse me for
> being not too happy to see that type again.
>
> -
> 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/
>
On Fri, Feb 15, 2002 at 07:14:17PM -0600, William Scott Lockwood III wrote:
> Here's an idea Al: Put up, or shut up. Where's your code to replace CML1
> with? I like Eric's system, and find it's MUCH more useful in a production
> environment than CML1 was. Where's your replacement idea?
I think Al's work on the kernel speaks for itself. He's been putting up
just fine, thank you. And I think you're looking in the wrong place,
Al has expressed no interest (that I'm aware of) in rewriting this code.
As a user of the new system, a pretty typical user, his opinion counts.
I don't think that you're really getting the point. Nobody is saying that
CML1 is the greatest thing since sliced bread. What they are saying is that
it seems to work pretty well, yes it could be better, but CML2 isn't shaping
up to be an improvement so much as a Eric Raymond Language exercise. Noone
begrudges Eric his right to come up with as many little languages as he wants.
But when he asks the kernel developers to use them, he'd better be prepared
to hear each and every thing they find wanting, and address the majority of
those issues. That hasn't happened. Instead, there have been a lot of
flame wars, politics, protests about Linus, etc.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
again, if you all would spend 1/10th of your time helping as opposed to just
slaming it, I'd be impressed. CML2 makes a WORLD of difference for me
personally. But hey, what do I know? I'm just a network administrator, I'm
not a kernel wizard, so feel free to just totally disregard my opinions...
----- Original Message -----
From: "Larry McVoy" <[email protected]>
To: "William Scott Lockwood III" <[email protected]>
Cc: "Alexander Viro" <[email protected]>; "Eric S. Raymond"
<[email protected]>; <[email protected]>
Sent: Friday, February 15, 2002 7:59 PM
Subject: Re: Disgusted with kbuild developers
> On Fri, Feb 15, 2002 at 07:14:17PM -0600, William Scott Lockwood III
wrote:
> > Here's an idea Al: Put up, or shut up. Where's your code to replace
CML1
> > with? I like Eric's system, and find it's MUCH more useful in a
production
> > environment than CML1 was. Where's your replacement idea?
>
> I think Al's work on the kernel speaks for itself. He's been putting up
> just fine, thank you. And I think you're looking in the wrong place,
> Al has expressed no interest (that I'm aware of) in rewriting this code.
> As a user of the new system, a pretty typical user, his opinion counts.
>
> I don't think that you're really getting the point. Nobody is saying that
> CML1 is the greatest thing since sliced bread. What they are saying is
that
> it seems to work pretty well, yes it could be better, but CML2 isn't
shaping
> up to be an improvement so much as a Eric Raymond Language exercise.
Noone
> begrudges Eric his right to come up with as many little languages as he
wants.
> But when he asks the kernel developers to use them, he'd better be
prepared
> to hear each and every thing they find wanting, and address the majority
of
> those issues. That hasn't happened. Instead, there have been a lot of
> flame wars, politics, protests about Linus, etc.
> --
> ---
> Larry McVoy lm at bitmover.com
http://www.bitmover.com/lm
>
On Sat, 16 Feb 2002, Dave Jones wrote:
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> > Eric has done it, without being of kernel hacker temple's fame.
>
> The kernel hacker approach: Gradual change toward a predefined goal.
> The Eric approach: Rip out existing, replace with new.
>
> If Al Viro can rewrite the guts of the VFS without hardly anyone
> noticing any disturbance, and the configuration system can't be
> done this way, something is amiss.
Not necessarily. If the gradual change infers intermediate functions
that are not needed for a hard cut-over, it's no good to do all the
extra work if the already-existing result is known to work. I'd
certainly not drop CML1 from 2.4, but 2.5 is the time for changes.
You don't take an airplane to drive alongs autobahns for a gradual
change either.
It seems to me as though the "rip out existing" issue was rather a
"don't let us maintain two parts of the same type at the same time"
convenience feature than a trait of CML2, and if so, keep both for some
releases and drop CML1 in, say, 2.5.8.
Also, it apears I am no longer getting messages from the list - thanks, whom
ever it was that killed me off the list. So nice of you to do that.
----- Original Message -----
From: "John Jasen" <[email protected]>
To: "Larry McVoy" <[email protected]>
Cc: "William Scott Lockwood III" <[email protected]>; "Alexander
Viro" <[email protected]>; "Eric S. Raymond" <[email protected]>;
<[email protected]>
Sent: Friday, February 15, 2002 10:17 PM
Subject: Re: Disgusted with kbuild developers
>
> If Microsoft really wanted to kill open source, they'd put you all in the
> same room together with weapons and tequila.
>
> --
> -- John E. Jasen ([email protected])
> -- In theory, theory and practise are the same. In practise, they aren't.
>
>
If Microsoft really wanted to kill open source, they'd put you all in the
same room together with weapons and tequila.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
Alan Cox wrote:
> Since the information is there in CML1 to generate the list of constraints
> for any given option, its a reasonable assertion that the entire CML2
> language rewrite is self indulgence from a self confessed language invention
> freak.
Correct me if I'm wrong, but there are express two different types of
situations, and CML1 isn't sufficient to express the second:
1) CONFIG_FOO_OPTION requires CONFIG_FOO
2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1
The reason why #2 is different, is the desired prompting and symbol
behavior for the end user.
If CONFIG_SUBSYS1=m or "", and CONFIG_SUBSYS2=y or m, then we gotta
change the value of CONFIG_SUBSYS1 and options underneath
CONFIG_SUBSYS1. Re-prompt for CONFIG_SUBSYS1, perhaps?
If CONFIG_SUBSYS1=y, value of CONFIG_SUBSYS2 isn't affected
If CONFIG_SUBSYS1="" and CONFIG_SUBSYS2="", then we gotta prompt for
CONFIG_SUBSYS1, but -after- CONFIG_SUBSYS2 is prompted for.
I was tempted to introduce a "requires" token to express dependencies
between subsystems, because I feel they are different from the other
dependencies present,
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
That Linux Guy wrote:
>
> The amount of whining I've had to read today on this topic just astonishes
> me. People, please - devote 1/10th of the energy to helping esr finish and
> fix CML2 to meet Linus' expectations. Face the fact: CML1 was good for
> it's time, but that time is now gone.
>
> If you spent as much time helping to get CML2 up and going as some of you
> have trying to kill it (while not offering anything constructive to replace
> it) it would have been DONE 6 months ago.
I consider CML2 an albatross now, and the maintainer does not listen to
feedback.
Contrary to what you think, I'm not trying to kill CML2. In it's
present state, according to kernel developers other than me, it is NOT
ready for inclusion. Now, by all appearances, Eric is trying to ram
CML2 down Linus's throat without resolving the problems kernel
developers have with it.
I would be happy as a clam if Eric wanted to resolve the problems -we-
have with CML1 and the config system, not just the problems he has with
it.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
Dave Jones wrote:
> Increased functionality I don't have a problem with, as long
> as other more important things are addressed. And for that matter,
> Linus has said to Eric "I don't care, take this out of the
> kernel completely leaving just oldconfig'.
That's a good point, and one I would be happy with. (or, ditch -all-
current config code, and replace with the existing mconfig)
Eric's configurator definitely seems to have a place with users. Making
kernel configuration easier for the masses is more than fine with me...
Impacting kernel developers' productivity and workflow because of this
is more of what I object to...
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
"Eric S. Raymond" wrote:
>
> Dave Jones <[email protected]>:
> > As you obviously completely ignored my previous point, I'll reiterate it.
> >
> > 1. You run Linus' split-into-config.in script on a 2.4 tree.
> > 2. You add whatever Config.ins have been updated to the 2.4 config.ins
> > 3. You regenerate with the find example I showed in the other mail.
> >
> > There. 2.4 Configure.help up to date with latest symbols, but
> > containing none of the 2.5 ones.
>
> And you've completely ignored the real problem...which is when I get
> a text change for one tree, *how do I automatically propagate it to
> the other*? How do I *tell* that it ought to be propagated?
It's easy as hell to propagate a Config[ure].help change across trees.
Linus even gave you the code to do it, when he split up Configure.help.
Configure.help is nothing but a database, with two different but
easy-to-parse formats in 2.4 and 2.5.
> Solutions that involve me doing an arbitrary and increasing amount of
> hand-hacking on every release are right out.
If you are hand-hacking Config[ure].help changes, you are wasting a lot
of time...
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
Rob Landley <[email protected]>:
> On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:
>
> > Solutions that involve me doing an arbitrary and increasing amount of
> > hand-hacking on every release are right out.
>
> Um, Eric? Isn't that what being a maintainer basically means?
The problem isn't that I'm not willing to work hard. I am. It's that
the level of handhacking has to be controlled below the threshold that
makes it impossible.
> Back up a bit. What would be the most minimal, stripped-down version of CML2
> you could write? No eye candy, no complications, no autoconfigurator, no
> tree view, no frozen symbols. Just solving the core problem of configuring
> 2.5 in a more flexible and less buggy way than CML1, with the three
> interfaces (oldconfig, menuconfig, xconfig) we've got now.
The big problem isn't the code transition. It's the rulebase transition.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Eric S. Raymond" wrote:
> Dave Jones <[email protected]>:
> > find . -name Config.help -exec cat {} >Configure.help \;
>
> Back-seat drivers. Answers for everything, understanding of nothing.
Did you read this in _How to Win Friends And Influence People_?
> Sorry, it's not *nearly* that simple. For one thing, one of the fourteen
> billion requirements I've had dropped on me is that Marcelo doesn't want
> any symbols in his help file that aren't actually in the 2.4 rulebase.
>
> So I'd have to generate a custom version for him. I used to have the
> machinery to do that by parsing magic comments in my master file.
> Until Linus blew it apart.
Linus also gave you C code which, slightly modified, could discern which
CONFIG_xxx help texts were needed for a given tree.
How hard is it to maintain a database where the key for each entry is
easy an unambigious?
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
"Eric S. Raymond" wrote:
> The first thing I heard, from mec two years ago, was "the CML1 code
> base is not salvageable". This was then and is now the unanimous opinion of
> the kbuild team. Not just mine; in fact, they concluded it before
> I entered the picture.
>
> I have seen nothing since to make me change that opinion.
So Alan Cox's opinion counts as nothing?
mconfig counts as nothing?
Anyway, I think you are missing the point. Sure, CML1 has problems, but
is your solution the one we want for the kernel? I do not think that is
clear yet. And bragging about a system's use in production tells us
little about its suitability for most kernel developers, or whether
you've addressed the global dependencies problem, or the syntax problem,
etc.
I'm sure CML2 configurator is whiz-bang, but it needs to do basic stuff
like having "make oldconfig" work exactly like it does in the current
config system.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
Jeff Garzik wrote:
> "Eric S. Raymond" wrote:
>
>>The first thing I heard, from mec two years ago, was "the CML1 code
>>base is not salvageable". This was then and is now the unanimous opinion of
>>the kbuild team. Not just mine; in fact, they concluded it before
>>I entered the picture.
>>
>>I have seen nothing since to make me change that opinion.
>>
>
> So Alan Cox's opinion counts as nothing?
> mconfig counts as nothing?
Why mconfig is not in the kernel? who maintain mconfig?
Why the first maintainer of mconfig prefer CML2?
>
> I'm sure CML2 configurator is whiz-bang, but it needs to do basic stuff
> like having "make oldconfig" work exactly like it does in the current
> config system.
now CML2 oldconfig behave like actual code. I would say too much.
giacomo
[email protected] said:
> The big problem isn't the code transition. It's the rulebase
> transition.
Only because you make it so.
I have no objection to the CML2 language and tools.
I've never done much more than glance at the CML1 mechanism, and as long as
"$EDITOR .config && make oldconfig" continues to work as expected I doubt
I'd ever pay any more attention to CML2.
I am aware that CML2 should allow me to more accurately represent some
things that CML1 couldn't, and I would welcome that.
However - the thing to which I and many others object most strongly is the
rulebase policy changes which appear to be inseparable from the change in
mechanism. That is; we've tried to get you to separate them, and failed.
As you keep saying, CML1 is a very limited language. If CML2 cannot even
represent the _existing_ CML1 ruleset, then I think you need to go back to
the drawing board.
I, for one, will have no objection to a merge of CML2 with an automated
translation of the CML1 rules. You can 'improve' the rulebase later, at
which point each change you want to make can be given individual attention.
You've said before that an automated translation is impossible. That's not
our problem - it's yours. Fix the CML2 language so it _is_ possible. If that
means adding ugly hacks to make it work, so be it - do it in the
expectation that you can fix the rulebase later and remove them again.
Eric, you have demonstrated repeatedly that your taste w.r.t the
configuration rules is extremely, erm, 'different' from that of the majority
of developers. I find it difficult to believe that a self-proclaimed
'hacker of social systems' cannot comprehend the need to strictly separate
the mechanism changes from the controversial rulebase changes.
--
dwmw2
Jeff Garzik wrote:
> Alan Cox wrote:
> > Since the information is there in CML1 to generate the list of constraints
> > for any given option, its a reasonable assertion that the entire CML2
> > language rewrite is self indulgence from a self confessed language invention
> > freak.
>
> Correct me if I'm wrong, but there are express two different types of
> situations, and CML1 isn't sufficient to express the second:
>
> 1) CONFIG_FOO_OPTION requires CONFIG_FOO
>
> 2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1
>
> The reason why #2 is different, is the desired prompting and symbol
> behavior for the end user.
>
> If CONFIG_SUBSYS1=m or "", and CONFIG_SUBSYS2=y or m, then we gotta
> change the value of CONFIG_SUBSYS1 and options underneath
> CONFIG_SUBSYS1. Re-prompt for CONFIG_SUBSYS1, perhaps?
IMHO that is a issue with the current *tools*, not with the CML1
*language*. The information about the dependences is there, a more
clever tool than "make config" can use them to present a better UI.
I have a 5-year-old perl script for kernel configuration, maybe
I should try to reactivate it and see ...
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
Eric S. Raymond wrote:
>Alexander Viro <[email protected]>:
>
>>>Neither Linus nor anyone else ever said to me "Eric, it's your job to
>>>make that change." When I asked for guidance, Linus blackholed my mail.
>>>
>>Oh! Come and see the violence inherent in the system!
>>Help! Help! I'm being repressed!
>>
>
>Your reply was pretty funny. Well, I laughed anyway.
>
You didn't reach for your usual potence substitute called a weapon?
Didn't you?
That Linux Guy wrote:
>The amount of whining I've had to read today on this topic just astonishes
>me. People, please - devote 1/10th of the energy to helping esr finish and
>fix CML2 to meet Linus' expectations. Face the fact: CML1 was good for
>it's time, but that time is now gone.
>
The fact is CML1 works fine enough for me. In fact fine engough means -
I never have
any problems with it. *THIS* is what makes the inclination to replace it
with something else
so low. And this is a good thing. No change for the sake of it is a
primal principle in good
software design.
Alan Cox wrote:
>>Alan Cox <[email protected]>:
>>
>>>Since the information is there in CML1 to generate the list of constraints
>>>for any given option,
>>>
>>False assumption...
>>
>
>Do you have anything more constructive that "doesnt" to say
>
>>If you want to refute me, build it yourself. You'll get a valuable learning
>>experience. At the end of it, I'll have earned your apology. Not that I
>>expect to get it.
>>
>
>Been there, done that, got the pretty graphs. Possibly the next step is to
>redo the work into mconfig which already does pretty much anything we need
>with the existing config files parsed using a real 100% genuine yacc grammar
>
I second this. mconfig is a fine lean and sane design, which isn't
trying to solve the "world hunger" problem.
Matthias Andree wrote:
>Eric has done it, without being of kernel hacker temple's fame.
>
>Whether he doesn't listen to other developers, I cannot tell, I got my
>/fetchmail/ issues resolved. Still, I share the opinion that the kernel
>
Fetchmail is a prime example for the fact that Eric isn't a capable
software designer.
Yes it is usefull, and works, but the configuration doesn't solve the
common problems
for which fetchmail is used in an easy way... I wouldn't like to have
something like
fetchmail for the kernel configuration.
On Sat, 16 Feb 2002, Jeff Garzik wrote:
> Dave Jones wrote:
> > Increased functionality I don't have a problem with, as long
> > as other more important things are addressed. And for that matter,
> > Linus has said to Eric "I don't care, take this out of the
> > kernel completely leaving just oldconfig'.
>
> That's a good point, and one I would be happy with. (or, ditch -all-
> current config code, and replace with the existing mconfig)
If so, then fairness of mconfig vs. CML2 tools should command that
mconfig's "old" mode works properly first. I reported to Christoph that
it always reprompts me about the kernel core format (a.out vs. ELF),
which is something "make oldconfig" does not do with the same config, he
acknowledged the bug, but I have yet to see the fix.
> Eric's configurator definitely seems to have a place with users. Making
> kernel configuration easier for the masses is more than fine with me...
> Impacting kernel developers' productivity and workflow because of this
> is more of what I object to...
Does that really happen? It looks as though the conversion of the
current config.in stuff has been completed as part of the CML2 suite.
> 1) CONFIG_FOO_OPTION requires CONFIG_FOO
> 2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1
>
> The reason why #2 is different, is the desired prompting and symbol
> behavior for the end user.
You can tell a subsystem from a module quite reliably because it has a
subtree of dependant questions. Now you might get it wrong, but its still
correct to prompt for the subtree of questions again since if you've just
forced on eepro100 for example, you do want to be asked mmio/pio and the
like
> If CONFIG_SUBSYS1="" and CONFIG_SUBSYS2="", then we gotta prompt for
> CONFIG_SUBSYS1, but -after- CONFIG_SUBSYS2 is prompted for.
The graph tells you that. The only interesting case I could find is the
negation one - some rules are A conflicts with B which makes the UI side
much more fun
On Sat, 16 Feb 2002, Martin Dalecki wrote:
> Matthias Andree wrote:
>
> >Eric has done it, without being of kernel hacker temple's fame.
> >
> >Whether he doesn't listen to other developers, I cannot tell, I got my
> >/fetchmail/ issues resolved. Still, I share the opinion that the kernel
> >
> Fetchmail is a prime example for the fact that Eric isn't a capable
> software designer.
> Yes it is usefull, and works, but the configuration doesn't solve the
> common problems
> for which fetchmail is used in an easy way... I wouldn't like to have
> something like
> fetchmail for the kernel configuration.
The point is not to discuss fetchmail ease of use or design or whatever.
CML2 is much younger, and in a much more maintainable language (or so I
believe, at last; Python vs. C).
The point I'm raising is that I cannot believe Eric would not care for
change requests right now, that contradicts my experience.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
David Woodhouse <[email protected]>:
> However - the thing to which I and many others object most strongly is the
> rulebase policy changes which appear to be inseparable from the change in
> mechanism. That is; we've tried to get you to separate them, and failed.
Failed? Hardly.
The only rulebase policy change Tom Rini was able to identify in a recent
review was the magic behavior of EXPERT with respect to entries without
help. Which I then removed by commenting out a single declaration.
There is a widespread myth that the CML2 rulebase is lousy with "policy
changes". I don't know how it got started, but it needs to die now.
Maybe I need to write a CML2 FAQ.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Alan Cox <[email protected]>:
> The graph tells you that. The only interesting case I could find is the
> negation one - some rules are A conflicts with B which makes the UI side
> much more fun
That's right. This is a CML2 require/prohibit construct. CML1 cannot
express this, and it's essential for side-effect forcing to work. Jeff's
observation about being tempted to introduce a `require' turns out actually
to be equivalent once you see how both problems generalize.
You can't deduce these constraints from graph analysis, because they're
not implicit in the if/then tree structure that is the only thing CML1
knows about.
Jeff and Alan have now almost caught up to where I was two years ago when
I realized the CMl1 formalism was inadequate.
This is going in the FAQ.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[email protected] said:
> David Woodhouse <[email protected]>:
> > However - the thing to which I and many others object most strongly is the
> > rulebase policy changes which appear to be inseparable from the change in
> > mechanism. That is; we've tried to get you to separate them, and failed.
> Failed? Hardly.
> The only rulebase policy change Tom Rini was able to identify in a
> recent review was the magic behavior of EXPERT with respect to entries
> without help. Which I then removed by commenting out a single
> declaration.
> There is a widespread myth that the CML2 rulebase is lousy with
> "policy changes". I don't know how it got started, but it needs to
> die now.
Each time I've even glanced at it, I've seen bogus changes. I haven't
looked at it recently, so cannot refute your statement that they are now
all gone. You'll forgive me if I take your assertion with a pinch of salt,
though?
A good way to kill this myth, if myth it is, would be to set up a test
suite, as I suggested before. You already have a 'randomconfig' for CML2, I
believe? I think there's also one for CML1.
Repeatedly make a random config (for a random architecture), with either
CML1 or CML2. Make oldconfig with the other CML, then with the first again.
If there are any differences between the original randomconfig output and
the output after the two 'oldconfig' stages, you've hit something that may
be a problem.
Every time you hit such a difference, either fix it or document it and
justify it. Ensure that the list of such justifications required is small,
in order to improve the chance of CML2 being accepted.
You are permitted to fix these differences by modifications to the CML1
rules. The only cases where you should accept differences are where the
CML1 behaviour does not accurately represent the intention of the
developer, the developer has agreed with you, _and_ CML2 cannot implement
the same buggy behaviour.
Note the third condition there. If CML2 _can_ implement the buggy CML1
behaviour, do so -- you can fix the rules _later_.
--
dwmw2
Jeff Garzik <[email protected]>:
> I consider CML2 an albatross now, and the maintainer does not listen to
> feedback.
New FAQ entry:
* Eric doesn't listen to feedback.
Bill Stearns observed in February 2002 that "Eric has been very good
about folding in changes". In response to feedback from the kernel
mailing list, Eric has:
- introduced the prefix declaration so that symbol names can be
expressed with or without the CONFIG_
- added a recovery mechanism so the configurator can do someting
with inconsistent configs (this one was Alan Cox's issue).
- removed the magic tie declaration that made symbols without help
only visible in EXPERT mode
- reorganized the rulebase to minimize stuff in the root rules file
- added the capability to annotate constraint violations with
text messages in English or the language of your choice.
- sped up the rulebase compiler by a factor of six
and many other changes comprising months of work.
> I would be happy as a clam if Eric wanted to resolve the problems -we-
> have with CML1 and the config system, not just the problems he has with
> it.
What problems do you have with CML1? Name them and I will make sure
they are not issues in CML2.
I've been begging for feedback for many months. Pleases *get specific*.
Instead of muttering that Eric refuses to listen, *give me something
to listen to*!
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Jeff Garzik <[email protected]>:
> Impacting kernel developers' productivity and workflow because of this
> is more of what I object to...
I still don't get why you think CML2 is going to interfere with your
workflow. Would you explain this to me, please?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Jeff Garzik <[email protected]>:
> How hard is it to maintain a database where the key for each entry is
> easy an unambigious?
It's not that simple, either. You have to track the symbols that are
*supposed* to be different between trees. The devil is in the details --
and it's a big devil.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
----- Original Message -----
From: "Eric S. Raymond" <[email protected]>
To: "David Woodhouse" <[email protected]>
Cc: "Rob Landley" <[email protected]>; "Dave Jones" <[email protected]>; "Larry
McVoy" <[email protected]>; "Arjan van de Ven" <[email protected]>;
<[email protected]>
Sent: Saturday, February 16, 2002 8:57 AM
Subject: Re: Disgusted with kbuild developers
> David Woodhouse <[email protected]>:
> > However - the thing to which I and many others object most strongly is the
> > rulebase policy changes which appear to be inseparable from the change in
> > mechanism. That is; we've tried to get you to separate them, and failed.
>
> Failed? Hardly.
>
> The only rulebase policy change Tom Rini was able to identify in a recent
> review was the magic behavior of EXPERT with respect to entries without
> help. Which I then removed by commenting out a single declaration.
>
> There is a widespread myth that the CML2 rulebase is lousy with "policy
> changes". I don't know how it got started, but it needs to die now.
The last time I played with CML2 (~2 months ago) I didn't even make it through a
full 'make config' before I had to stop on account of nausea. It was seemingly
overrun with gratuitous changes that were (to me, anyway) useless and annoying.
Examples:
* It started asking me vague questions like how old my computer was in order to
draw some magic conclusion about my configuration needs. *I* know my hardware.
Don't waste my time with Aunt Tillie questions that will quite possibly draw the
wrong conclusion for my needs.
* The 'make config' UI was subtly changed from the CML1 version. Why? I haven't
seen any complaints on the list about the UI.
* The 'make menuconfig' UI was significantly changed. Again, why? Haven't seen
any complaints about the old one.
Maybe these issues don't qualify as "policy change" but it seems obvious that
there is some other agenda being followed here besides replacing the CML1
language with one that can accurately represent the rulebase. I'm in favor of
the later, but definitely not if it comes inseparably packaged with the former.
--Adam
"Eric S. Raymond" wrote:
> What problems do you have with CML1? Name them and I will make sure
> they are not issues in CML2.
>
> I've been begging for feedback for many months. Pleases *get specific*.
> Instead of muttering that Eric refuses to listen, *give me something
> to listen to*!
(cc'ing Linus)
1) Remove global dependencies.
> source "arch/um/rules.cml"
> source "arch/i386/rules.cml"
> source "arch/alpha/rules.cml"
> source "arch/sparc/rules.cml"
[...]
All symbols should not be included on every config run. The
architectures currently create their own master rules file, which then
selectively includes other config files. You break this and remove
control (and flexibility) by enforcing something globally which was
previously done on a per-arch basis.
2) As discussed in December (as well as before and after that thread),
the --eventual-- direction to go is that a single file will contain all
meta information about a driver or set of drivers. Config.help entries,
Config.in entries, Makefile rules, etc. The idea is to group
information about a particular object in the same location. So,
considering (a) that Config.help now exists and (b) this eventual
direction, splitting up rules and symbols into completely separate files
is not the greatest idea... when we eventually want to integrate rules
and symbols.
Take a look at what we find in Donald Becker's virgin source tree, in
winbond-840.c:
> /* Automatically extracted configuration info:
> probe-func: winbond840_probe
> config-in: tristate 'Winbond W89c840 Ethernet support' CONFIG_WINBOND_840
>
> c-help-name: Winbond W89c840 PCI Ethernet support
> c-help-symbol: CONFIG_WINBOND_840
> c-help: The winbond-840.c driver is for the Winbond W89c840 chip.
> c-help: This chip is named TX9882 on the Compex RL100-ATX board.
> c-help: More specific information and updates are available from
> c-help: http://www.scyld.com/network/drivers.html
> */
All the information is in one location. Now, Linus said not to embed
this information in the source, but put it in a metadata file. But
other than that, this is a small and simple example of what the metadata
config files might eventually look like.
So, my own personal opinion is that CML2 should follow these suggestions
:)
Regards,
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
"Eric S. Raymond" wrote:
>
> Jeff Garzik <[email protected]>:
> > Impacting kernel developers' productivity and workflow because of this
> > is more of what I object to...
>
> I still don't get why you think CML2 is going to interfere with your
> workflow. Would you explain this to me, please?
(please read "CML2 feedback" message before this...)
Ideally in the future I can add and update a driver's makefile and
configuration information by patching drivers/net/netdriver.c and
drivers/net/netdriver.conf, and touch absolutely no other files.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, Feb 16, 2002 at 02:04:14PM +0100, Matthias Andree wrote:
>
> The point is not to discuss fetchmail ease of use or design or whatever.
> CML2 is much younger, and in a much more maintainable language (or so I
> believe, at last; Python vs. C).
I am not so convinced about this "much more" in practice. As an
"interested observer", but not a Python programmer, I watch for quite a
while a set of programs written in Python which affect me directly;
namely Red Hat configuration/installation tools. Literally for years
and many releases bombs and inscrutable Python tracebacks were the
constant element of this picture. These tools, after an obvious and
long effort, are now finally in much better shape then they used to be
but bugs are regularly reintroduced with every change.
I do not think that this happens because Red Hat has lazy or incompetent
people but because these problems are hard and Python is quite far from
silver bullet and "sliced bread" its proponent wants us to believe. I
rather suspect that all behind the scenes machinations by Python rather
mask difficulties and make harder to eradicte those bugs.
I also cannot help not to notice that the previous bit flare-up about
CML2 on lkml was quelled to a great extent when somebody annouced that
he is rewriting required tools in C. I had an impression that most
people then shrugged "Ok, so Eric will prototope in whatever he feels
comfortable with, we will have something acceptable later and we will
see how this works". Now it turns out the the project got abandoned so
a requirement for a huge blob of a language (as opposed to Python 1.5
which is quite smaller), which most developers do not have or need for
anything else, is still there. Hm..., smells very backdoor even if
it was not intended that way.
Michal
On Sat, 16 Feb 2002, Eric S. Raymond wrote:
> Jeff Garzik <[email protected]>:
> > I consider CML2 an albatross now, and the maintainer does not listen to
> > feedback.
>
> New FAQ entry:
>
> * Eric doesn't listen to feedback.
>
> Bill Stearns observed in February 2002 that "Eric has been very good
> about folding in changes". In response to feedback from the kernel
> mailing list, Eric has:
[...]
Eric has selectively listened to feedback he found interesting and still
persist in resisting most others.
You ignored mine so far, even if they are like the ones made by many others.
Make the whole thing ___***IDENTICAL***___ to CML1.
Do a formal translation of CML1 into CML2.
Show us that you are clever enough to do so, even if it's not particularly
interesting and challenging to you.
Show us that you can listen to this simple feedback.
Acknoledge that the feedback went through.
Don't tell us that's not doable. Do it and show us that you can do a
perfect translation of CML1 into CML2 with all CML1 structural flaws.
Submit that, and only that.
Do you copy? Please acknoledge that you listened to this very feedback.
Nicolas
Jeff Garzik <[email protected]>:
> Ideally in the future I can add and update a driver's makefile and
> configuration information by patching drivers/net/netdriver.c and
> drivers/net/netdriver.conf, and touch absolutely no other files.
That's very much the direction I'd like to go in, Jeff. I'm
surprised and delighted to hear you say this. You're actually
anticipating my plans for six months down the road. Maybe we
have some common ground here.
One of the objectives of the CML2 language design is to make it
amenable to being generated by a metadata analyzer. I mean some very
specific things by this.
One important property which CML2 declarations have that CML1 syntax
does not is that (a) they're not order-dependent, and (b) they have
strong locality (that is, the syntactic context of a single
declaration holds all the semantic information -- you don't have to go
monkey-climbing up a bunch of enclosing syntax to parse it, or
*generate* a bunch of enclosing syntax to express it).
These properties tremendously simplify generating a rulebase from
(so far hypothetical) analysis tools. My first step would be to
automatically generate CML2 bus-guard information from annotations
in the driver sources. Once I write a tool that can do that, I can whack
about 25% of the rulebase, including most of the parts that are a
maintainance headache.
My longer-term plan is to whittle away at the manually-maintained
rulebase until nothing but menu structure and a handful of cross-
directory requirements are left. Everything else should be generated
by a program that turns source-code metadata into stereotyped CML2
markup.
Even a lot of the menu structure might be generatable, requiring it
to be specified only in exception cases where as a matter of UI design
choice you don't want to track the code hierarchy.
This has been part of my long-term plan since about eighteen months
ago. It's had a major, *major* impact on the language design. In
particular it's one of the reasons visibility and implication
can be declared separately from the menu structure.
If you go back and look at the language design from this point of view,
I think many things you might not have seen the point of before will
become clearer.
Note well two points:
1. This can't practicably be done in CML1. CML1 markup has crappy
locality; the metadata analyzer would have to carry around way too
much state about other symbols in order to generate the markup for any
given one.
2. This design basically demands a single-apex tree. Otherwise I don't
think you can get the consistency-checking right -- I haven't been
able to invent a method to do it, anyway.
So if you want this, please start backing CML2 and contributing in a
positive way. I know how to get where you want to go. CML2 is
specifically intentionally designed to make it possible, and I have the
will to follow through.
But for these good things to happen, CML2 *got to go in*. I cannot both
continue the enormous effort of maintaining a parallel rulebase
and move the ball forward towards automatic rule generation from metadata
and other good things. That's what I want to be working on.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Alan Cox <[email protected]>:
> > The kernel rulebase cannot. The real issue here is whether the CML1
> > language carries sufficient information to support things like
> > side-effect deduction. And the answer is "no".
>
> Thats an opinion not an answer. What doesn't it contain ?
New FAQ entry:
* Inventing CML2 was unnecessary, since CML1 carries enough information to
do consistency checking and side-effect forcing.
Jeff Garzik observed:
>I was tempted to introduce a "requires" token to express dependencies
>between subsystems, because I feel they are different from the other
>dependencies present,
Alan followed up with:
>The only interesting case I could find is the negation one - some
>rules are A conflicts with B which makes the UI side much more fun
Jeff and Alan have put their finger neatly on one of the key bits CML2
can do that CML1 cannot -- express cross-directory dependencies in
such a way that the configurator can force side effects in both
directions. This is, in fact, the very rock on which my original
attempt to save CML1 foundered after six weeks of effort.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
David Woodhouse <[email protected]>:
> A good way to kill this myth, if myth it is, would be to set up a test
> suite, as I suggested before. You already have a 'randomconfig' for CML2, I
> believe? I think there's also one for CML1.
There is no randomconfig for CML2.
> Repeatedly make a random config (for a random architecture), with either
> CML1 or CML2. Make oldconfig with the other CML, then with the first again.
> If there are any differences between the original randomconfig output and
> the output after the two 'oldconfig' stages, you've hit something that may
> be a problem.
>
> Every time you hit such a difference, either fix it or document it and
> justify it. Ensure that the list of such justifications required is small,
> in order to improve the chance of CML2 being accepted.
This cycle is what I've been going through with a lot of my beta testers.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> Jeff and Alan have put their finger neatly on one of the key bits CML2
> can do that CML1 cannot -- express cross-directory dependencies in
> such a way that the configurator can force side effects in both
> directions. This is, in fact, the very rock on which my original
> attempt to save CML1 foundered after six weeks of effort.
You can force a side effect in both directions. The language provides the
information to do that, the current -toolset- can't handle this.
At any point you ask a question you can "wind back" and compute the set
of changes that are needed and re-ask only the needed questions.
Nicolas Pitre <[email protected]>:
> Show us that you're able to write a 1 for 1 functional correspondance
> between CML1 and CML2 and propose that for inclusion into 2.5.
This requirement is absurd. When someone designs a new VM, we
don't demand that it crash or lock up the system in exactly the same
way that the old one did before it can go into the kernel.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Nicolas Pitre <[email protected]>:
> Make the whole thing ___***IDENTICAL***___ to CML1.
> Do a formal translation of CML1 into CML2.
>
> Show us that you are clever enough to do so, even if it's not particularly
> interesting and challenging to you.
>
> Show us that you can listen to this simple feedback.
>
> Acknoledge that the feedback went through.
>
> Don't tell us that's not doable. Do it and show us that you can do a
> perfect translation of CML1 into CML2 with all CML1 structural flaws.
>
> Submit that, and only that.
>
> Do you copy? Please acknoledge that you listened to this very feedback.
I listened.
Would you ask someone designing a new VM to make it crash and hang exactly
the same way the old one did?
Do you demand that a rewrite of a disk driver have the same data-corruption
bugs as the original before it can go into the tree, and tell the developer
to add fixes later?
Pragmatically, the point of rewriting a system is to *fix bugs*.
Let's suppose we ignored this point for a moment. Let's also suppose
that what you were demanding were not rendered horribly painful and
perhaps impossible by the difference between CML1's imperative style
and CML2's declarative one.
How the hell do you possibly think I could possibly stay motivated under
that constraint? Nobody is paying me to do this. I'm a volunteer; I
need to produce good art, not waste time slavishly recreating old errors
just because a few people are unreasonably fearful of change.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Eric S. Raymond" wrote:
> But for these good things to happen, CML2 *got to go in*. I cannot both
> continue the enormous effort of maintaining a parallel rulebase
> and move the ball forward towards automatic rule generation from metadata
> and other good things. That's what I want to be working on.
Global dependencies... CML1 doesn't have this now, and it needs never
to have it. This is no point in merging a design change of that
magnitude only to take it away later on. Further, merging a rulebase
which contains such dependencies would be a huge mistake that might take
years to undo. drivers/net/rules.cml doesn't need S/390 stuff in it,
AFAICT, and that is a simple example of a bug found in many of the
rules.cml files.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
"Eric S. Raymond" wrote:
> Let's suppose we ignored this point for a moment. Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.
>
> How the hell do you possibly think I could possibly stay motivated under
> that constraint? Nobody is paying me to do this. I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.
If you are not prepared to evolve the system, you are not familiar with
kernel development... Prove that CML2 is good and needed by breaking it
up into steps, reaching the final goal... Good ole Al Viro's patch
progressions are an excellent example to emulate :)
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
> It's not that simple, either. You have to track the symbols that are
> *supposed* to be different between trees. The devil is in the details --
> and it's a big devil.
(Not tested but something like this ought to split them neatly out of
a master tree into the 2.4 format)
for i in $(find . -name "[Cc]onfig.in" -print)
do
grep CONFIG_ '$i'
done | sort -u |
while read x
do
grep -B1 -A200 '$x' MasterConfigHelpFile |
(
read A
read B
cat > frob
)
ed frob << 'FOO'
/^$
.,$d
wq
'FOO' >/dev/null
cat frob
done
Alan Cox <[email protected]>:
> You can force a side effect in both directions. The language provides the
> information to do that, the current -toolset- can't handle this.
>
> At any point you ask a question you can "wind back" and compute the set
> of changes that are needed and re-ask only the needed questions.
I spent over a month in early 2000 trying a similar approach. I tried it
with CML1, and I tried it with increasingly enriched dialects of CML1
(magic comments carrying extra semantic information, that sort of thing).
The results were (a) ugly, and (b) broken. I struggled against this
for a long time, because I knew what a horrible revolving bitch and
maintaining a parallel rulebase in a new formalism was going to be.
As you no doubt realize, the problem of deducing the forcing
information from CMl1 markup is efectively equivalent to the problem
of writing a mechanical CML1-to-CML2 translator. So I have a
suggestion: if you want to prove that it's possible to extract all the
info for side-effect forcing from CML1, do it by writing such a
translator.
I believe you will fail, as I did and as Jeff Garzik implicitly predicted.
If you fail, the process will teach you what I had to learn the hard way
two years back. If you succeed, people who are whingeing about wanting
a bug-for-bug rulebase translation will get what they want.
Don't tell me to do it. Been there, done that, have the battle scars.
If there were any way I could have avoided maintaining my own rulebase,
you better believe I'd have done it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Alan Cox wrote:
>
> > Jeff and Alan have put their finger neatly on one of the key bits CML2
> > can do that CML1 cannot -- express cross-directory dependencies in
> > such a way that the configurator can force side effects in both
> > directions. This is, in fact, the very rock on which my original
> > attempt to save CML1 foundered after six weeks of effort.
>
> You can force a side effect in both directions.
Yup, good point.
I mentioned "requires" as a way of avoiding 'both directions' in some
cases.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
"Eric S. Raymond" wrote:
> I believe you will fail, as I did and as Jeff Garzik implicitly predicted.
no, I didn't, don't put imaginary words in my mouth.
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, 16 Feb 2002, Eric S. Raymond wrote:
> Nicolas Pitre <[email protected]>:
> > Show us that you're able to write a 1 for 1 functional correspondance
> > between CML1 and CML2 and propose that for inclusion into 2.5.
>
> This requirement is absurd. When someone designs a new VM, we
> don't demand that it crash or lock up the system in exactly the same
> way that the old one did before it can go into the kernel.
When someone design a new VM, and decides that it must be written in a
totally new language with a new compiler, that someone will certainly face
big resistance unless it can be proven that the new language can do exactly
the same as the old one so other developers can get used to it first...
especially if the old VM doesn't crash the system that often or maybe never
for many users.
So yes, it might look absurd from your point of view but it's not for most
people not familiar with CML2. And if that's what most of your opponants
are asking for why don't you give them just that? Prove them that you're
able to _split_ the concepts apart i.e. first the language vocabulary and
tools, then the improved grammar, then the advanced configuration features,
then the ultimate philosophical changes, etc.
Wake up Eric!
If people want A, B, C, agree somewhat with D, but have problems with E, do
you realise that they will reject the whole thing at once if the only way
you can present things is by submiting ABCDEFG indistinguishly?
Do things in steps. First the struct translation of CML1 into CML2 with the
new coherent frontends. That's it. If you can't do that then give up now
and don't spent more time on CML2 because it will never go anywhere as the
Linux kernel is concerned.
Nicolas
> of writing a mechanical CML1-to-CML2 translator. So I have a
> suggestion: if you want to prove that it's possible to extract all the
> info for side-effect forcing from CML1, do it by writing such a
> translator.
I'd rather focus on making the existing tools better. If you want to
convert the data into Erics pet format on the fly *you* do the work.
Jeff Garzik <[email protected]>:
> Global dependencies... CML1 doesn't have this now, and it needs never
> to have it. This is no point in merging a design change of that
> magnitude only to take it away later on. Further, merging a rulebase
> which contains such dependencies would be a huge mistake that might take
> years to undo. drivers/net/rules.cml doesn't need S/390 stuff in it,
> AFAICT, and that is a simple example of a bug found in many of the
> rules.cml files.
All right. There are a couple of ways we can attack this -- I have
some ideas. But I want a meta-question answered first. If we solve
this issue, *are you on board*?
I've got to get off the fscking treadmill I'm on now where I'm spending
so much time on the parallel-rulebase maintainance and the flaming
politics that I can't really get anything else done.
After what you wrote upthread, I don't think you want me to be stuck
either. Fact: ain't nobody else visible with both the motivation and
skills to tackle what you want done. I've been thinking about
metadata-centered configuration and consciously bending CML2's design
towards it for longer than anyone else has even been considering the
problem.
I *will* get us there -- I think the last two years have demonstrated
my determination. But to do it, I need alliance rather than
obstruction. I need you to tell Linus that your concerns have been met
and sponsor CML2 to go in, so I can stop perpetually re-fighting old
battles.
Because we agree on getting to metadata-centered configuration, your
requirements list now appears to have shrunk to one. You want to
"eliminate global depencies". I hear that. I got it.
What I want to know is that this is not a proxy for "CML2 can never be
good enough" and that you'll be pulling more objections out of your butt
till the Sun goes nova. Because if that's true there's no point in
my trying to work with you.
But if "eliminate global depencies" is it, we can be allies, because
ultimately we both want to get the config system to the same place.
I've taken the first, biggest step -- from imperative code to
declaration/constraint language. The second -- from a
declaration/constraint language to a metadata-centered system --
will be easier.
A positive answer may be "Yes, that's it, let's go forward", or
"Almost, there are a couple other minor and negotiable issues *which I
will now list*" (where "Minor and negotiable" = "I don't have to scrap
my architecture").
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Eric S. Raymond" wrote:
> But if "eliminate global depencies" is it, we can be allies, because
> ultimately we both want to get the config system to the same place.
> I've taken the first, biggest step -- from imperative code to
> declaration/constraint language. The second -- from a
> declaration/constraint language to a metadata-centered system --
> will be easier.
Well, let's simmer things down a bit and see what other people have to
say. Maybe I'm completely off base.
But to answer the question which the subtext seemed to asking (at least
to me), no, there is no vendetta against you. And for the record on a
specific detail, I have no problem with python use. If I have no major
objection based purely on technical grounds, that what you'll be hearing
from me.
And further, in 2.5.x series at least, minor objections can be worked
through after a kernel merge. But major objections... that's not the
time when something -must- -go- -in-.
Regards,
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, 16 Feb 2002, Eric S. Raymond wrote:
> Nicolas Pitre <[email protected]>:
> > Do you copy? Please acknoledge that you listened to this very feedback.
>
> I listened.
Good. We therefore can make progress.
By your comments below we now know that you listened and that it's
extremely painful for you to admit the truth. But you must understand the
nuances if you want to go somewhere with CML2.
> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
>
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?
Your examples are flawed. The person who fix bugs in the VM doesn't use any
other language than the original one. The person who do a rewrite of a disk
driver doesn't change anything in the struct rational purpose of reading and
writing blocks of bytes on a media.
> Pragmatically, the point of rewriting a system is to *fix bugs*.
Indeed! However CML2 is __way__ more than only bug fixing. If you qualify
your current CML2 inclusion proposal as only "bug fixes" it's much too much
under estimating the work you did and the effort you put in it.
I'm sure people will agree with the fact that the CML2 syntax is much more
enjoyable to read and work with. The fact that all frontends are using the
same parser eliminates bugs already. That's the part most people have
nothing against. For god sake submit those parts and leave the rest for a
later discussion!
Admit that in the tremendous work you did, there are parts that people will
disagree with. Don't spoil it all by not separating things and only
presenting it as a big unknown blat!
For people to have confidence in CML2 it must be proposed in multiple
incremental changes -- changes that are small enough (either conceptually or
physically) for people to be able to grok them without too much effort. You
must also be prepared to see people wanting to modify things in some ways
you didn't think about along the process. That's why only producing a
strict CML1 --> CML2 translation would already be a big enough step for now.
> Let's suppose we ignored this point for a moment. Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.
Do what's necessary so the translation is a near as possible and the result
in say 'make config' is the same (same questions as before). You certainly
can do that with some bits of awk. If you can't come with something
similar, you're then already admiting yourself that CML2 is so big a change
that people are right to be afraid of it.
> How the hell do you possibly think I could possibly stay motivated under
> that constraint? Nobody is paying me to do this. I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.
First, by doing what I described above, you'll please more people than you
can imagine. Next you must be prepared to face the possibility that your
art might not be adopted integrally. You should be motivated by the
percentage that gets adopted in the end.
When Al Viro decides to rewrite the VFS, he doesn't submit it to Linus as a
single big opaque patch to replace the old code at once. If he did, he
would probably still be waiting for Linus to merge his art.
Note the nuance: we don't criticize your art but rather the way you present
it. It might be the best configuration tool ever, but untroduce it in
incremental steps and leave some slack between them for those who didn't
work on it for the last year to digest them. Please be wise so not to waste
your art.
Nicolas
> I need you to tell Linus that your concerns have been met
> and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> battles.
That's a fine thing for anyone and everyone to say *after* they have
used the system and like it.
If you are asking for a blessing in advance, which is how I read that,
I would think there is zero chance of that happening, it's not how work
is done on the kernel.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]>:
> > I need you to tell Linus that your concerns have been met
> > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > battles.
>
> That's a fine thing for anyone and everyone to say *after* they have
> used the system and like it.
>
> If you are asking for a blessing in advance, which is how I read that,
> I would think there is zero chance of that happening, it's not how work
> is done on the kernel.
We're talking about design objections here. Specific objections to actual
CML2 bugs, including rulebase and UI bugs, are a different level. What
I am asking is if Jeff will bless the *architecture* provided the global-
dependency issue is met.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Eric S. Raymond" wrote:
> Larry McVoy <[email protected]>:
> > > I need you to tell Linus that your concerns have been met
> > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > battles.
> >
> > That's a fine thing for anyone and everyone to say *after* they have
> > used the system and like it.
> >
> > If you are asking for a blessing in advance, which is how I read that,
> > I would think there is zero chance of that happening, it's not how work
> > is done on the kernel.
>
> We're talking about design objections here. Specific objections to actual
> CML2 bugs, including rulebase and UI bugs, are a different level. What
> I am asking is if Jeff will bless the *architecture* provided the global-
> dependency issue is met.
Larry's right. I won't (and notice, did not in previous e-mail) provide
a pre-blessing. I will promise to be fair.
But as I said, let's wait a bit and see what others say. Alan for
example noted that bit about improving the existing tools.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, Feb 16, 2002 at 12:16:34PM -0500, Eric S. Raymond wrote:
> Larry McVoy <[email protected]>:
> > > I need you to tell Linus that your concerns have been met
> > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > battles.
> >
> > That's a fine thing for anyone and everyone to say *after* they have
> > used the system and like it.
> >
> > If you are asking for a blessing in advance, which is how I read that,
> > I would think there is zero chance of that happening, it's not how work
> > is done on the kernel.
>
> We're talking about design objections here. Specific objections to actual
> CML2 bugs, including rulebase and UI bugs, are a different level. What
> I am asking is if Jeff will bless the *architecture* provided the global-
> dependency issue is met.
See your quote above which contains "and sponsor CML2 to go in". Code is
what goes in. Having the right architecture is great, we all agree, but
what goes in is code. So your question above is basically "if I do this
will you pressure Linus to accept my *code*". The answer to that should
always be "no". You're trying to do an end run around the process. The
process here is to let people see the changes, try the changes, refine
the changes, and when they are ready, Linus accepts the changes. Nowhere
in that process is any deal making. What you are doing is a lot like the
skating judges, making deals. Your code should go in evaluated on its
merits. That's the beauty of the system. It doesn't matter who *you*
are, the code is the only thing. So you can be universally loved and
your code might not make it in. You can be universally hated, and your
code can make it in. That's a pretty cool system and I'd suggest that
you stop trying to work around it and just make your code be something
that people want. Then it will go in. No deals necessary.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Jeff Garzik <[email protected]>:
> Well, let's simmer things down a bit and see what other people have to
> say. Maybe I'm completely off base.
Jeff, I'm not asking "other people". I'm asking *you*.
You're one of the people Linus says he trusts. Linus has said,
explicitly, to myself and Dave Jones, on this very issue, "get me out
of the loop". My take is that if you switch from opposing CML2 to
supporting it, the political wars will probably be about over.
I hope the prospect of actually getting to a metadata-centered
configuration system in our lifetime will be sufficient incentive for
you to do so. Oh lovely dream...I could have a prototype
metadata-to-CML2-bus-guards translator in less than two weeks, I
think, if I didn't have to maintain the CML2 rulebase all by myself. I
want to go there.
> But to answer the question which the subtext seemed to asking (at least
> to me), no, there is no vendetta against you. And for the record on a
> specific detail, I have no problem with python use. If I have no major
> objection based purely on technical grounds, that what you'll be hearing
> from me.
OK. Is "global dependencies" your sole technical showstopper? If so,
can we dispose of the ill-defined "CML2 will fuck up my workflow" thing?
If you tell me yes, we can move to a discussion of why global
dependencies are a problem and how to solve it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
On Saturday 16 February 2002 01:35 am, Eric S. Raymond wrote:
> Rob Landley <[email protected]>:
> > On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:
> > > Solutions that involve me doing an arbitrary and increasing amount of
> > > hand-hacking on every release are right out.
> >
> > Um, Eric? Isn't that what being a maintainer basically means?
>
> The problem isn't that I'm not willing to work hard. I am. It's that
> the level of handhacking has to be controlled below the threshold that
> makes it impossible.
That's still not the point. You had great tools to do a job Linus -wasn't
interested in having done-. Unsuprisingly, Linus broke them. Linus wasn't
trying to make more work for you as 2.5 help file maintainer, he simply
didn't care about side projects outside of 2.5.
It's still a question of defining the work you're expected to do. Keeping
2.4 and 2.5 in sync was a job you invented. Initially it was easy, later it
stopped being easy, and eventually it became a very hard problem indeed to
the point where you had to stop doing it. But the dependency between the 2.4
and 2.5 help files was always completely artificial. That you thought
maintaining it was expected of you all along was an honest miscommunication,
but that's water under the bridge now.
> > Back up a bit. What would be the most minimal, stripped-down version of
> > CML2 you could write? No eye candy, no complications, no
> > autoconfigurator, no tree view, no frozen symbols. Just solving the core
> > problem of configuring 2.5 in a more flexible and less buggy way than
> > CML1, with the three interfaces (oldconfig, menuconfig, xconfig) we've
> > got now.
>
> The big problem isn't the code transition. It's the rulebase transition.
Then why confuse the two?
Eric, "make menuconfig" is now green text on a black background. The old one
was black and yellow text on grey boxes with a blue border. They look
NOTHING alike. The tab-through buttons at the bottom have gone away, the
list now takes up the whole screen horizontally and vertically instead of
being confined to a curses box, and the rest of the keys you use to do stuff
are different. (q does nothing in the old menuconfig, x gives you the option
to abort, and cursor left and right changes which button is highlighted.
Looking back, yes "?" pulls up help in CML1 but I didn't need to know that.
I never used it, I always tabbed over to "help" and hit enter. And I never
used "x" to exit, I tabbed over to the "exit" button and used it until I got
out of the top level menu. It's all I ever needed to know to make it work...)
I personally don't care about the other configurators since the only one I
ever use is menuconfig. And after using CML2 for a while, I'll even grant
that the old CML1 interface was clunky and the new one is probably an
improvement. But that's not the POINT.
It IS a different interface. For no apparent reason except that you don't
want to implement the old one. Pull them up side by side in two different
windows and try to do the same config in paralell. The difference is pretty
darn obvious.
Remember when I asked for a blank line at the top of menuconfig and you went
"no, that's a waste of screen space" and refused to even consider it? We
went back and forth for ten minutes on this issue. Look at how MUCH of the
old menuconfig is wasted in drawing boxes and drop shadows: there's only ten
lines of actual menu. (Your code doesn't have any blank lines in it either.
Mine does. Does this sound like a coding style flame war to you? Do you see
how it's an issue on which a judgement call from you might not suddenly
resolve all debate?)
Your aesthetic judgement of how the interface should look is not the point.
Can you or can you not make one that looks and acts like the old one? Yes or
no? (Yes it IS a trivial problem relative to the rest of the codebase, but
it's one that hasn't been addressed. And considering the UI is what people
actually see, and it's different, you're giving a horrible first impression
on the compatability front.)
I don't care if it's "better". New Coke was "better". It won all the blind
taste tests hands down. The fact CML2 asks the same questions and produces
exactly the same .config files as the old rulebase is a blind taste test
issue. In real life, people aren't blindfolded, and the first thing they're
seeing is a profoundly different user interface, for no readily apparent
reason except that you don't like the old one.
Change the colors. Put in the tabbable buttons. Waste over half the
screen space with boxes and drop shadows. Suppress your gag reflex. Prove
it can be done. Feel free to keep the old green menuconfig in the separate
tarball with the autoconfigurator and call it "mconfig" or something, just
try to make it so that when a developer runs "make menuconfig" they can't
TELL whether they're running cml1 or cml2 (unless a difference they bump into
is a REALLY obvious and justifiable no-brainer bugfix, like the stupid ).
And the same for oldconfig and xconfig. -THAT- is far more likely to get
merged.
Yes this IS a showstopper issue. Really. Honest. Stop giving objectors
such an amazingly obvious target...
Rob
On Sat, 16 Feb 2002, Eric S. Raymond wrote:
> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
>
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?
>
> Pragmatically, the point of rewriting a system is to *fix bugs*.
That, folks, is a fine example of very common problem.
It's very tempting to try and force your ideas of How The Things
Should Be Done(tm) into the tree by bundling them with genuine
bug fixes and (more or less gracefully) refusing to split the
patch. Anybody who had done serious work on the tree had felt
that temptation at one point or another. No arguments - it's very
attractive. Indeed, you don't have to defend every point of your
design and implementation - you can always point to Bad Bugs(tm)
that are fixed by the entire thing and obfuscate the objections away.
The trouble being, _SUCH_ _BUNDLING_ _IS_ _NOT_ _A_ _VALID_ _STRATEGY_.
It had been tried. Many times. Sometimes it even got the
thing into the tree. _All_ such cases had lead to trouble.
There is another way. It takes more efforts, it requires
readiness to defend every damn part of your design and it means
that you will have to deal with the sad fact that parts of that
design need to be redone. It will take more time. It will look
less sexy. It may very well mean that somebody else will get
alternative design into the tree on the top of your efforts.
There are only two positive things about it - it is honest and
it leads to better tree.
How does it work? Simple - look at the path from original
tree to tree with your modifications. And no, "one big jump" doesn't
count. Think of the way your ideas can be split into parts. Think
of the way obstructions to the changes can be split into parts.
Find small and simple changes that can go in right now, would improve
the tree and would make the rest of path easier. And merge them.
If you find that it can't be done - think what needs to be changed in
the tree (or in your modifications) to make the split possible.
If you see that something is ugly and stands in the way - help the thing
to achieve the form it wants. That may change all your ideas about the
right design for your modifications. That's OK - it's a Good Thing(tm).
And merge the small changes. Step by step.
_That_ works. Less glory; more time; more work. And better
tree afterwards. The code wants to get cleaner. In many directions.
The trick is to pick the right ones and let the thing grow into natural
form. Do that many times in the right order and you will get it where
you want it to be. Quite possibly - in a better place than you thought
originally.
Before you start saying that it's impossible - THAT HAD BEEN DONE.
Between 2.3.40 and 2.5.2 (about two years) we got pretty much complete
redesign of VFS, along with the stuff that was plain impossible with
the old design. Get the old tree. Get the current tree. Compare. And
realize that more than half of the way was covered during 2.4. Yes, the
total size of patches had been about 2 times larger than the size of
combined patch. Definitely took a lot of extra efforts. You know what?
It was worth the trouble. Result is better than what I've expected. And
a lot of things in the first iteration of design had turned out to be
useless - stuff that was there to work around the problems that got _fixed_
by cleanups at some point during these two years. And I fully expect to
see the same thing happening with the stuff I'm planning and doing now.
While we are at it, look what Rik is doing right now. He has
a huge patch pretty much rewriting (what a coincidence) VM. He had tried
to shove its previous incarnations into the tree whole-sale. Saying that
it didn't work is putting it _very_ mildly - resulting fight is in l-k
archives and boy, was it nasty... Look what's going on now - same splitup
and gradual merge strategy. Sure, extra work. Guess what? The thing had
already become better from that work.
As for your motivations... If you are doing that for bragging
rights ("I've thought up a new design and now it's in the tree, exactly
as I envisioned it") - find something else to brag about. Your strategy
is basically a sign of cowardice - you are fighting tooth and nail to avoid
gradual changes and the only way I can interpret it is that you are afraid
to let parts of your design stand on their own. Not exactly a bragging
material, that...
"Eric S. Raymond" wrote:
>
> Jeff Garzik <[email protected]>:
> > Well, let's simmer things down a bit and see what other people have to
> > say. Maybe I'm completely off base.
>
> Jeff, I'm not asking "other people". I'm asking *you*.
>
> You're one of the people Linus says he trusts. Linus has said,
> explicitly, to myself and Dave Jones, on this very issue, "get me out
> of the loop". My take is that if you switch from opposing CML2 to
> supporting it, the political wars will probably be about over.
Shit... don't inflate my stock more than it's worth.
I'm not giving a pre-blessing to any, but I'm willing to give something
an honest and fair review.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, 16 Feb 2002, Alexander Viro wrote:
> While we are at it, look what Rik is doing right now. He has
> a huge patch pretty much rewriting (what a coincidence) VM. He had tried
> to shove its previous incarnations into the tree whole-sale.
Actually, Linus took it unexpectedly while I was away to
Europe for conferences for 2 weeks. ;)
I don't quite agree on the "more trouble" part either,
in the end it is MUCH more trouble when a big blob of
code gets integrated than when a series of small changes
get applied one by one.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, Feb 16, 2002 at 11:08:57AM -0500, Eric S. Raymond wrote:
> Nicolas Pitre <[email protected]>:
> > Make the whole thing ___***IDENTICAL***___ to CML1.
> > Do a formal translation of CML1 into CML2.
>
> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
Eric, that's a slippery-slope argument. You are bright enough
to know that is not what they meant.
I like to stay out of flamewars, so I'm going to be nice,
simple, and to the point. I hack kernels. I build a lot of them. I
use only make config and make oldconfig. Here is what I want from a
config system (be it CML1 or CML2):
make config goes through and asks me all the questions it needs
to. The order can be different. The slight format of the prompts can
be different. The backend can be wildly different. I don't CARE. What
I do care about is that it only asks me relevant questions. No "How old
is your computer?" Never a "Do you like the color blue?" None of that.
if it wants to know my CPU, it asks "What is your cpu? [386 486
Pentium/K6 ...]" If it wants to know if I want sound support it asks
"Configure sound support?" That's it. I use make config because it
asks me every question, and I'm sure I haven't missed any. When it is
done, I even know the macros it has set in config.h so I can peruse them
in the source.
make oldconfig has to work like make old config. Again, trivial
differences in the output layout don't matter. Totally different logic
dont matter. All that matters is that configuration questions I have
answered already don't get asked, and questions that are new to this
kernel do.
The configuration metadata should be as close to the actual item
as possible. I think everyone has come to this agreement. You know,
drivers/scsi/aic_7xxx/aic_7xxx.cml or the like. Fine. I'm not even
sure that I care all that much about this. So if everyone can come to a
level of agreement on this, I'm sure I'll be fine.
The last thing I require is that it doesn't affect my build
time. The kernel takes a while to build right now, even on my
dual-GHz machines with >GB RAM. I've not played with CML2 much, but the
rumours of it taking twice as long for a build are scary. CML2 should
have completed all of its work when make *config exited. All of the
logic after the completion of make *config and make dep should be in the
Makefiles, just like it does in CML1. Now, if I've got that wrong, let
me know. I sure hope you aren't executing CML2 programs during make
bzImage.
Until CML2 can come to do this, I'm going to stay perfectly
happy with CML1. mconfig just makes it easier.
Joel
--
"The first requisite of a good citizen in this republic of ours
is that he shall be able and willing to pull his weight."
- Theodore Roosevelt
http://www.jlbec.org/
[email protected]
Thus spake Nicolas Pitre ([email protected]):
> As a bonus to further stimulate acceptance of CML2, make it work with the
> tools that most people already have i.e. Python 1.5.
I don't have python. Any version of python.
And I refuse to use software that forces me to install an ugly
monstrosity like python. Integrating python in the build process is
like integrating IE into Windows. It may please the stupid masses who
use Red Hat anyway and don't care what happens when they click their
mouse button, but it's conceptually bad for the OS and the kernel so far
went to great lengths to not depend on external bloat. It is a good
thing to minimize dependencies! If you can't do it in C and /bin/sh,
then please step aside and let someone handle the job who is up to it.
So far this looks like you are on one hell of an ego trip.
Felix
Thus spake Eric S. Raymond ([email protected]):
> Jeff, I'm not asking "other people". I'm asking *you*.
> You're one of the people Linus says he trusts.
Eric, why don't you try to make a system that is not openly disgusting
and revolting? The kernel affects everyone. Bribing congress is a
tactic worthy of Microsoft, not of you. Please concentrate on making
good software and not on fast talking to Jeff until he takes a
sabbatical to get some rest at all.
The more of your mails about CML I see, the more I am disgusted with it.
On Sat, 16 Feb 2002, Rob Landley wrote:
> On Saturday 16 February 2002 11:06 am, Nicolas Pitre wrote:
>
> > Don't tell us that's not doable. Do it and show us that you can do a
> > perfect translation of CML1 into CML2 with all CML1 structural flaws.
>
> "Hey, the new VM in 2.4.10 should have replicated the swap overload failure
> case in 2.4.9! The first implementation should definitely melt down exactly
> the same way! We need to artificially introduce all the flaws in the old
> one, just to prove it can be done! Otherwise the new code is not
> interesting."
Rob:
Please read my other mails, understand the nuances, then come back, OK?
Nicolas
I'm the creator and one of the current administrators of the kbuild-devel
mailing list. kbuild-devel is not an instrument of "cronyism" or
"secret meetings".
I think it's reasonable and scalable for kernel subsystems to have their
own mailing lists. And I think it's reasonable to expect people who
have an interest in a subsystem to look in MAINTAINERS for any mailing
lists and web sites for that subsystem. As of 2.5.4, the MAINTAINERS
file lists 91 such mailing lists, including:
CONFIGURE, MENUCONFIG, XCONFIG
L: [email protected]
W: http://kbuild.sourceforge.net
Yeah, some cabal I started here, cleverly hidden in MAINTAINERS.
When Eric Raymond started the CML2 project, he came to the CML1 maintainer
(me) and asked me what I thought. I referred him to the public list and
we had a public discussion about the project. The root of the discussion
is here:
http://www.torque.net/kbuild/archive/0181.html
So while people are chastising Eric for bundling controversial
improvements with CML2, or pushing for a 2.4 backport, or writing in
python, or writing in python2, I think it's unfair to suggest that he
developed CML2 in secret. He didn't. He read the MAINTAINERS file
and then held numerous discussions in the appropriate public forum.
You may reject the fruits of his project, but I'm here to say that he
developed it in an open fashion.
(I have to say, reluctantly, that I'm personally not happy with the tactic
of asking kbuild-devel people to send mail to Dirk Hohndel. I don't have
any acquaintance with Dirk, but I'm sure that he's capable of writing
to kbuild-devel himself if he wants to solicit opinions from there.
I say "reluctantly" because as an administrator of the list, I don't want
to get into criticism of list postings.)
As far as CML1 goes: I got discouraged in April 2000, when Linus
blackholed documentation patches from me for several months in a row.
So I took a hiatus for two years. Two things have changed since then:
Linus agreed to be more responsive, and other people (specifically Dave
Jones) are offering kernel trees. So I'm going to give it another shot.
I'm responding to every CML1 patch and bug report which is submitted to
kbuild-devel, and I'm sending patches to Linus and Dave.
I believe that CML1 is rococo and I welcome a replacement. I think that
leapfrog development is a good strategy here, just as it was for ALSA.
I'll look after the current system, and other people can focus their
attention on the next generation.
Here are my reasons for wanting to get rid of CML1:
. A Microsoft engineer wrote scripts/Configure. For three years, I have
lived in fear that Microsoft would notice this fact and use it to attack
Linux through public relations channels or legal means. They haven't yet,
so I have been wrong so far.
. A language must have a written definition, so that people writing
scripts in the language have a good chance that their scripts will keep
working as other people enhance the configuration tools. CML1 has
a retro-fitted language definition with lots of gaps in it.
. An implementation must have a real parser that gives real syntax errors.
Menuconfig in particular likes to get all weird if there are syntax
errors in the input. xconfig used to crash a lot in those cases;
but it has gotten better.
. The language itself does not scale up to the thousands of symbols that
we have today. There's a fundamental tension between "hide all the
symbols for busses that I don't have" and "I want this feature,
so auto-enable everything I need to get it".
As far as which way to replace CML1 goes: I'm not worried about the
technical specifications of the language, so long as it has one. I would
like to remove every trace of Microsoft intellectual property from the
kernel, which is an argument in favor of a new language as well
as a new implementation. I would like the new system to come with plenty
of documentation. And I would like the new system to have a maintainer
who really believes in it. CML2 has these properties so I support it.
Other projects, such as Christoph Hellwig's current version of mconfig,
also have these properties (except for keeping the same language) and
are also viable replacements for configure/Menuconfig/xconfig.
Michael Elizabeth Chastain
<mailto:[email protected]>
"love without fear"
Nicolas Pitre <[email protected]>:
> Show us that you're able to write a 1 for 1 functional correspondance
> between CML1 and CML2 and propose that for inclusion into 2.5
Eric S. Raymond <[email protected]>:
> This requirement is absurd. When someone designs a new VM, we
> don't demand that it crash or lock up the system in exactly the same
> way that the old one did before it can go into the kernel.
I disagree with this statement in three different ways.
[1] lkml readers are kbuild users, not kbuild developers
kbuild is special. The relationship between most lkml readers and most
linux kernel code (such as the VM) is the relationship of developers to
a corpus of code. The relationship of most lkml readers to kbuild is
the relationship of *users* to a corpus of code. I think of everybody
that has not submitted patches or written code to kbuild tools as a
kbuild user.
Oddly enough, people behave differently in their roles as users than
their roles as developers. Many people who have actually worked on
menuconfig would love to shitcan that monstrosity, but people who run
menuconfig don't mind the ugliness of its implementation.
The first thing users want to know about a software upgrade is: "is it
going to break what I am doing right now". In a mature system, it really
is better to leave 10 old bugs unfixed rather than introduce one new bug.
I believe that is why people ask for functional equivalence, even for bugs.
Users do not trust developers to decide which behaviours are bugs!
In order to do my work, it has to match some internal concepts I have
about correctness, elegance, robustness, all that stuff. But in order
for other people to want to use my work, it has to match their concepts
of what is useful to them.
[2] CML1 is working in the field
Your view is that CML1 is as bad as a VM that crashes or locks up.
This view is rejected by a significant number of CML1 users, including a
lot of influential ones. People are building kernels with CML1 every day.
Even if you believe that CML1 as a language has hopeless problems, you
should acknowledge that many users do not believe this. So when you
show up and say "here, CML2 language will solve all your CML1 language
problems", you are offering a lot of people something negative or neutral
to them.
A month ago I was disenheartened about this. It looked like CML1
language was going to be "good enough" for the entire lifespan of the
Linux kernel. Now it turns out that there is a new customer requirement:
people want driver.conf files. A new language has the opportunity to
define driver.conf files and that would be a significant advantage
over CML1.
[3] kernel development is highly multi-threaded with interesting locks
The kernel development process involves hundreds of people across several
trees. It's fundamentally different from one person writing code on
one branch of one tree -- the same way that a massive multi-threaded
program running on a 256-processor server is programmed differently than
a single-threaded program on a uniprocessor.
I believe there are development locks. I could probably write a
whole essay on the nature of these locks, the atomic operations in the
development process, the way that people use multi-phase protocols to
get something merged without grabbing giant locks, and so on.
Kbuild work has the unfortunate property that it sometimes needs big
locks. I think that CML2 involves a giant lock: you want to lock every
Config.in file at once, modify it from top to bottom, and commit them
all at once. Okay. That's a huge lock, especially considering that
at any given moment, lots of people have unmerged work-in-progress,
as well as whole parallel trees.
Linus can acquire a lock that big, because sometimes he just grabs the
Big Kernel Development Lock, changes some interface, and relies on us
mortals to patch up the loose edges. This works pretty well because
it leverages his vision by letting other people share the grunt work.
But I think that Linus prefers to avoid grabbing the BKDL, and it's no
use pushing him.
I think it would be good for you to think about the nature of this locking
process (starting with: is mec onto something here or is he delusional?)
Then think about how to get to the end vision of CML2 with a less
severe locking strategy.
Michael Elizabeth Chastain
<mailto:[email protected]>
"love without fear"
I can't believe you people, even if you are high level kernel
maintainers.
The most major complaints I see against CML2 are that 'the
behaviour is different from CML1' and 'CML2 has a whole bunch of
"features" too which will be shoved down our throats'.
Duh! That was the freaking point! Granted I'm not a kernel hacking
expert, but I've been building my own kernels since 1995 and I see
definite value in having the side effects and grouping stuff in
CML2. I also see significant value in having the symbol set and
rules provably coherent.
You guys change the low level kernel interfaces all the time. You
change module interfaces out from underneath people every other
month. You depreciate malloc.h and replace it with slab.h and
don't so much as give it a second thought, yet you bitch up a
storm about how the changes in CML2 behaviour are unacceptable?
You guys force changes down the throats of other people all the
time. Well now, in my lowly opinion, it's time for you to do what
everyone else is already used to - choke it down, and comfort
yourself by saying 'it was the right thing to do.'
Looking forward to seeing CML2 in 2.5,
-dennis T
Larry McVoy wrote:
> On Sat, Feb 16, 2002 at 12:16:34PM -0500, Eric S. Raymond wrote:
> > Larry McVoy <[email protected]>:
> > > > I need you to tell Linus that your concerns have been met
> > > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > > battles.
> > >
> > > That's a fine thing for anyone and everyone to say *after* they have
> > > used the system and like it.
> > >
> > > If you are asking for a blessing in advance, which is how I read that,
> > > I would think there is zero chance of that happening, it's not how work
> > > is done on the kernel.
> >
> > We're talking about design objections here. Specific objections to actual
> > CML2 bugs, including rulebase and UI bugs, are a different level. What
> > I am asking is if Jeff will bless the *architecture* provided the global-
> > dependency issue is met.
>
> See your quote above which contains "and sponsor CML2 to go in". Code is
> what goes in. Having the right architecture is great, we all agree, but
> what goes in is code. So your question above is basically "if I do this
> will you pressure Linus to accept my *code*". The answer to that should
> always be "no".
Sometimes I'm willing to vouch for the quality of the *code*, and I
want a "go ahead and do it" from the kernel crowd.
Writing the code without consensus on the architecture can make you
have to go back to architecting when people have architectural
objections.
Part of the problem is that in a company the manager is in the end
responsible for the salary of the guy doing the work. So he'll work
along an try to make a good architecture before doing the actual
coding.
For Linus it costs just one Email to say: "Hmm. Maybe. Show me the
code!", and reject the code later on.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Larry McVoy wrote:
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> >
> > If that's not what you mean, stop reading this mail, drop a line to
> > clarify this and forget this piece of mail.
>
> That's not what I mean. But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do". And that is not what kernel programmers do. They would
> love to be able to do that but it's very rare that doing so makes sense.
Sometimes the "old" code is set up in such a way that the "right" way
to do it is not possible. That doesn't make the last guy "stupid": it
can be that when he did it, that was the right way to do things, but
that we've learned since then.
If the "cleanup" would result in changing more than say 60% of the
code, then a rewrite is in order. The old code is usually still in
place. That will allow you to "steal" code that is not the core of the
rewrite: just copy it.
I've heard that someone is trying to revolutionize "source code
control systems". He's rewriting almost everything, and not enhancing
any previous systems. What was his name again?
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
On Saturday 16 February 2002 11:06 am, Nicolas Pitre wrote:
> Don't tell us that's not doable. Do it and show us that you can do a
> perfect translation of CML1 into CML2 with all CML1 structural flaws.
"Hey, the new VM in 2.4.10 should have replicated the swap overload failure
case in 2.4.9! The first implementation should definitely melt down exactly
the same way! We need to artificially introduce all the flaws in the old
one, just to prove it can be done! Otherwise the new code is not
interesting."
"To get people to try Linux on the desktop, first we need to make it
blue-screen just like windows."
"It's unfair to compare laptops to desktops unless you first remove the
battery from the laptop."
What the...?
Wouldn't it be nice if there was an implementation of CML2 that did
everything CML1 did -EXCEPT- for the structural flaws? Rather than a blind
mindless drooling bug-for-bug clone that defeats the whole purpose of
reimplementing the thing?
Your requirement seems to be based on the blind assumption that CML1 had
nothing whatsoever wrong with it, and CML2 didn't need to be done in the
first place. If that's your argument, then say it directly. (That might be
a defendable position. The one you just stated isn't.)
As for breaking CML2 so it's capable of producing a configuration that the
rulebase says won't compile, the way CML1 can... You do understand the
difference between a procedural and a declarative language, right?
Rob
On Mon, Feb 18, 2002 at 10:41:03AM +0100, Rogier Wolff wrote:
> Larry McVoy wrote:
> > That's not what I mean. But it's worthwhile to note that almost all
> > "rewrite from scratch" projects really translate into "I'm unwilling to
> > learn what the last guy did, and I'm smarter, so I'm going to do what
> > I want to do". And that is not what kernel programmers do. They would
> > love to be able to do that but it's very rare that doing so makes sense.
>
> Sometimes the "old" code is set up in such a way that the "right" way
> to do it is not possible.
_Sometimes_ that is true. But there is no way you are going to be able to
say that that is the typical case. History says otherwise. I'm not saying
that rewrites aren't necessary, I'm saying that many, maybe most, aren't
necessary.
> I've heard that someone is trying to revolutionize "source code
> control systems". He's rewriting almost everything, and not enhancing
> any previous systems. What was his name again?
The fact that BitKeeper will read and write 30 year old SCCS files
seems to have escaped your attention. Contrast that with the CML
debate and I think it makes my point perfectly. If Eric's changes
worked the same way, we'd have a system which worked on the old data
and the new.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
[ everything deleted ]
Wow, I'm amazed at the amount of time spent on this thread,
when people could have actually been doing real work, or
maybe just enjoying family, friends, life ...
I hope it comes to some useful resolutions,
--Matt
On Sat, 16 Feb 2002, Nicolas Pitre wrote:
> Make the whole thing ___***IDENTICAL***___ to CML1.
> Do a formal translation of CML1 into CML2.
This requirement is contrary to CML2's objective. CML2 is not about
re-implementing CML1 tools and bugs in another language, there are at
least two current projects for that, one of them is mconfig.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Michael Elizabeth Chastain wrote:
> I'm the creator and one of the current administrators of the kbuild-devel
> mailing list. kbuild-devel is not an instrument of "cronyism" or
> "secret meetings".
[reshuffle the message a bit]
> (I have to say, reluctantly, that I'm personally not happy with the tactic
> of asking kbuild-devel people to send mail to Dirk Hohndel. I don't have
> any acquaintance with Dirk, but I'm sure that he's capable of writing
> to kbuild-devel himself if he wants to solicit opinions from there.
> I say "reluctantly" because as an administrator of the list, I don't want
> to get into criticism of list postings.)
I never meant to suggest that about kbuild-devel -- having the
appearance of being an attempt to [IMO] push a bad change via Dirk when
pushing it other ways [IMO] failed was really offensive to me...
> I think it's reasonable and scalable for kernel subsystems to have their
> own mailing lists.
No argument
> So while people are chastising Eric for bundling controversial
> improvements with CML2, or pushing for a 2.4 backport, or writing in
> python, or writing in python2, I think it's unfair to suggest that he
> developed CML2 in secret. He didn't.
No one's suggesting that. It's more the appearance of "I couldn't do it
the normal way, let me try this other, non-open route..."
> I believe that CML1 is rococo and I welcome a replacement. I think that
> leapfrog development is a good strategy here, just as it was for ALSA.
I think this is a key mistake. See Al's message "Of Bundling, Dao,
...".
It's impossible to prove that Eric's CML2 rulebase reflects a current
CML1 rulebase, primarily for this reason. My review of arch/alpha/* and
drivers/net/* configs between CML1 and CML2 showed divergent rules and
dependencies which simply don't exist in CML1 and often should not in
CML2.
Surely we can prove through -evolution- that CML2 is or is not the best
direction for the future. All or nothing is this case is impossible to
prove correctness.
> Here are my reasons for wanting to get rid of CML1:
no arguments
> As far as which way to replace CML1 goes: I'm not worried about the
> technical specifications of the language, so long as it has one. I would
> like to remove every trace of Microsoft intellectual property from the
> kernel, which is an argument in favor of a new language as well
> as a new implementation. I would like the new system to come with plenty
> of documentation. And I would like the new system to have a maintainer
> who really believes in it. CML2 has these properties so I support it.
Those are meta-properties. The origin of code, be it MicroSoft or not,
should not be a factor. In fact, -allowing- it to be a factor is
allowing MicroSoft some additional weight in technical decisions, which
should not occur IMO.
CML2 has global dependencies that the current system does not.
CML2 has a rulebase which is different from the current rulebase, with
no documentation or adequate explanation for these changes, and with no
good way to prove these changes are correct and reflect the current
rulebase for [pick your tree].
CML2's syntax is not reflective of the direction of being able to plop
down "driver.c" and "driver.conf" and having the config/make system
magically notice it. It goes in the opposite direction, increasing the
number of places in $cml-rules-file that one must patch when adding a
driver [especially one with strange arch-specific dependencies, such as
an S/390-specific net driver].
> Other projects, such as Christoph Hellwig's current version of mconfig,
> also have these properties (except for keeping the same language) and
> are also viable replacements for configure/Menuconfig/xconfig.
Would you support the replacement of in-kernel
configure/Menuconfig/xconfig with in-kernel mconfig?
I mentioned this to Christoph, and he violently disagreed that it should
go into the kernel, and I violently disgreed with him :) The kernel
absolutely MUST have some in-kernel configuration currently. And
mconfig is clearly a better tool.
If we want to migrate to a point where all kernel configuration is
maintained solely outside the kernel, I actually support that. But as a
SEPARATE migration step. I do not want to drop all config tools from
the kernel and tell people "use mconfig" in the same breath.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Sat, 16 Feb 2002, Michal Jaegermann wrote:
> I also cannot help not to notice that the previous bit flare-up about
> CML2 on lkml was quelled to a great extent when somebody annouced that
> he is rewriting required tools in C. I had an impression that most
> people then shrugged "Ok, so Eric will prototope in whatever he feels
> comfortable with, we will have something acceptable later and we will
> see how this works". Now it turns out the the project got abandoned so
> a requirement for a huge blob of a language (as opposed to Python 1.5
> which is quite smaller), which most developers do not have or need for
> anything else, is still there. Hm..., smells very backdoor even if
> it was not intended that way.
I recall there has been a complete patch set to make CML2 work with
Python 1.5.2, if the two (2) in "Python 2" is your concern. The archives
should tell us more.
(I'm not jumping into the other part of your mail on Python vs. Red Hat
configurator bugs because I don't know that particular tool and didn't
review its internal design.)
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
On February 16, 2002 03:08 am, William Scott Lockwood III wrote:
> again, if you all would spend 1/10th of your time helping as opposed to just
> slaming it, I'd be impressed. CML2 makes a WORLD of difference for me
> personally.
Could you elaborate on that please?
> But hey, what do I know? I'm just a network administrator, I'm
> not a kernel wizard, so feel free to just totally disregard my opinions...
--
Daniel
In article <[email protected]> you write:
>I don't quite agree on the "more trouble" part either,
>in the end it is MUCH more trouble when a big blob of
>code gets integrated than when a series of small changes
>get applied one by one.
I would say "more than one idea" here, if something need changes in a
lot of places, so be it, they often won't work except as a whole. You
don't cross vast chasms in a series of small safe steps.
Hanging multiple indenpendent things in a single blob is bad practice,
of course.
--
bill davidsen <[email protected]> CTO, TMR Associates, Inc
Programming without software engineering is like sculpting with a chain
saw. The very talented can produce a work of art, the mediocre wind up with
a misshapen lump in a pile of rubble, and in neither case does the end
result have more than a passing resemblance to the original intent.
> . A Microsoft engineer wrote scripts/Configure. For three years, I have
> lived in fear that Microsoft would notice this fact and use it to attack
> Linux through public relations channels or legal means. They haven't yet,
> so I have been wrong so far.
Teehee. I don't think you have anything to worry about, Microsoft would be
incredibly embarassed to admit they're contributing to 'problem number 1'.
--
Daniel
On February 18, 2002 04:15 pm, SodaPop wrote:
> I can't believe you people, even if you are high level kernel
> maintainers.
>
> The most major complaints I see against CML2 are that 'the
> behaviour is different from CML1' and 'CML2 has a whole bunch of
> "features" too which will be shoved down our throats'.
>
> Duh! That was the freaking point! Granted I'm not a kernel hacking
> expert, but I've been building my own kernels since 1995 and I see
> definite value in having the side effects and grouping stuff in
> CML2. I also see significant value in having the symbol set and
> rules provably coherent.
>
> You guys change the low level kernel interfaces all the time. You
> change module interfaces out from underneath people every other
> month. You depreciate malloc.h and replace it with slab.h and
> don't so much as give it a second thought, yet you bitch up a
> storm about how the changes in CML2 behaviour are unacceptable?
Right. The bitching and moaning is stupid. Lets move on.
> You guys force changes down the throats of other people all the
> time. Well now, in my lowly opinion, it's time for you to do what
> everyone else is already used to - choke it down, and comfort
> yourself by saying 'it was the right thing to do.'
>
> Looking forward to seeing CML2 in 2.5,
Yup.
--
Daniel
Matthias Andree wrote:
> On Sat, 16 Feb 2002, Nicolas Pitre wrote:
>
>
>>Make the whole thing ___***IDENTICAL***___ to CML1.
>>Do a formal translation of CML1 into CML2.
>>
>
> This requirement is contrary to CML2's objective. CML2 is not about
> re-implementing CML1 tools and bugs in another language, there are at
> least two current projects for that, one of them is mconfig.
But making the translation in 3 steps make think easier:
- Change the engine (CML2), the rules are rewritten, but
functionally nearly identical to old rules
(Big patch)
- Change the rules (with a lot of small patches)
- Change the interface (not really need)
giacomo
Daniel Phillips wrote:
>>. A Microsoft engineer wrote scripts/Configure. For three years, I have
>> lived in fear that Microsoft would notice this fact and use it to attack
>> Linux through public relations channels or legal means. They haven't yet,
>> so I have been wrong so far.
>>
>
> Teehee. I don't think you have anything to worry about, Microsoft would be
> incredibly embarassed to admit they're contributing to 'problem number 1'.
I agree, but we know some strange 'behaviour' of MS.
They have a lot of lawers, they can make us a lot of trouble.
(You will notice that there are no copyright statment on that file,
only the name of authors).
Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
way to include 'free' patches: sign and send to FSF a piece of paper,
that the patches CAN be included.
I think nobody in Linux have done that, thus we can expect some
more troubles and microsoft is a large troubles-maker
giacomo
On Tue, 19 Feb 2002, Giacomo Catenazzi wrote:
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
>
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker
... and script in question is fscking trivial to reimplement if and when it
happens. End of story.
On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:
> Daniel Phillips wrote:
> >>. A Microsoft engineer wrote scripts/Configure. For three years, I have
> >> lived in fear that Microsoft would notice this fact and use it to attack
> >> Linux through public relations channels or legal means. They haven't
> >> yet, so I have been wrong so far.
> >
> > Teehee. I don't think you have anything to worry about, Microsoft would
> > be incredibly embarassed to admit they're contributing to 'problem number
> > 1'.
>
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
>
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
Under the GPL Having exclusive copyright just means that you can relicense
later stuff if you want. I'm not clear on why FSF considers it so important
but for Linux it just means that nobody, not even Linus, can ever release
under a new license (e.g., the BSD license). So actually, having multiple
copyright holders is a good thing for you, it protects your investment in GPL
capital better. I say, if Microsoft employees want to contribute to Linux,
the more the merrier. Heck, even billg is going to wake up on day (with a
start, in the middle of the night) and realize which way the wind is blowing.
Steve Jobs did.
> I think nobody in Linux have done that,
Great.
> thus we can expect some more troubles and microsoft is a large
> troubles-maker
Oh yes...
--
Daniel
G'day,
Michal Jaegermann <[email protected]> wrote:
>
> I also cannot help not to notice that the previous bit flare-up about
> CML2 on lkml was quelled to a great extent when somebody annouced that
> he is rewriting required tools in C.
I believe I'm the anonymous `he' you refer to.
> I had an impression that most
> people then shrugged "Ok, so Eric will prototope in whatever he feels
> comfortable with, we will have something acceptable later and we will
> see how this works".
I had the impression that most people just stopped whingeing on lkml
but didn't actually try the code. I've had very very little feedback
or apparent interest on gcml2. In the meantime ESR's Python code got
less buggy and faster and I upgraded my main devel box to a distro
which had Python2 on it. The Python code had limped up to the `adequate'
mark and my time is finite so I moved on.
Look if I thought gcml2 was a serious contender to be used as the kernel
config tool of choice I would drop everything else and finish it.
> Now it turns out the the project got abandoned [...] Hm..., smells
> very backdoor even if it was not intended that way.
So you're implying that I colluded with ESR to use gcml2 as a decoy
to ease acceptance of his Python2 implementation? Hah, I *wish* I was
that organised or devious!
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
Greg Banks wrote:
> G'day,
>
> Michal Jaegermann <[email protected]> wrote:
>
>>I also cannot help not to notice that the previous bit flare-up about
>>CML2 on lkml was quelled to a great extent when somebody annouced that
>>he is rewriting required tools in C.
>>
>
> I believe I'm the anonymous `he' you refer to.
There are two other projects of C implementation of CML2:
cml2config in sourceforce, and another I lost the link.
giacomo
Giacomo Catenazzi wrote:
>
> There are two other projects of C implementation of CML2:
>
> cml2config in sourceforce,
I've spoken with these guys. They're using Prolog and a new
language which they're inventing. Their goal of a smarter inference
engine is interesting from a theoretical point of view, but if you
don't like Python you're going to *loathe* their stuff.
> and another I lost the link.
Well, good luck to them, whoever they are.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
Hi!
> . A Microsoft engineer wrote scripts/Configure. For three years, I have
> lived in fear that Microsoft would notice this fact and use it to attack
> Linux through public relations channels or legal means. They haven't yet,
> so I have been wrong so far.
What's problem with Microsoft people helping with configure? Not *all* of them
are evil. And GPL is designed to prevent legal abuse from them.
I can't imagine PR attack. "Oh, look, we helped to develop Linux and it
is not killing us"?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> Alan, don't talk to me about "proof of concept". Tell me about a
> production-quality system, proven in use by people like Embedsys,
> Webmachines, and the Compache project. Tell me you can duplicate what
What are you trying to say? New configuration system needs to be
tested by big company before you want to hear about it?
"I do not care what kernel developers say, they are all stupid, but my
stuff is used by Embedsys, Webmachines and Compache, so it must be
good and you are all stupid."
No wonder Linus ignores you.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Tue, 19 Feb 2002, Daniel Phillips wrote:
> On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:
> Under the GPL Having exclusive copyright just means that you can relicense
> later stuff if you want. I'm not clear on why FSF considers it so important
> but for Linux it just means that nobody, not even Linus, can ever release
> under a new license (e.g., the BSD license). So actually, having multiple
> copyright holders is a good thing for you, it protects your investment in GPL
> capital better. I say, if Microsoft employees want to contribute to Linux,
> the more the merrier. Heck, even billg is going to wake up on day (with a
> start, in the middle of the night) and realize which way the wind is blowing.
> Steve Jobs did.
So did IBM, SCO, HP and Sun. We shall see what transpires...
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Pavel Machek <[email protected]>:
> What are you trying to say? New configuration system needs to be
> tested by big company before you want to hear about it?
No, of course not. Two of the three projects I cited are open-source
developments.
My point should have been obvious. Alan is talking as though his
supposed "proof of concept" is as good an argument as a tested,
production-quality system. Of course, it is not.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Thus spake Michael Elizabeth Chastain ([email protected]):
> . A Microsoft engineer wrote scripts/Configure. For three years, I have
> lived in fear that Microsoft would notice this fact and use it to attack
> Linux through public relations channels or legal means. They haven't yet,
> so I have been wrong so far.
That is not something Microsoft could leverage.
Actually, it is something Linux can leverage against Microsoft, because
Microsoft keeps on telling people that using GPL is a nightmare because
it forces all your intellectual property on the street for free. They
proved that wrong themselves. That is quite a strong argument. It
should be publicized, not buried. We should thank them publicly.
Felix
> That is not something Microsoft could leverage.
> Actually, it is something Linux can leverage against Microsoft, because
> Microsoft keeps on telling people that using GPL is a nightmare because
> it forces all your intellectual property on the street for free. They
> proved that wrong themselves. That is quite a strong argument. It
> should be publicized, not buried. We should thank them publicly.
>
> Felix
Don't read too much into this. As I understand it, the "Microsoft Engineer"
that wrote scripts/configure did this work on his own time, not as part of a
Microsoft project team.
Keith
On Mon, Feb 18, 2002 at 06:27:43PM +0000, Felix von Leitner wrote:
> Thus spake Eric S. Raymond ([email protected]):
> > Jeff, I'm not asking "other people". I'm asking *you*.
>
> > You're one of the people Linus says he trusts.
>
> Eric, why don't you try to make a system that is not openly disgusting
> and revolting? The kernel affects everyone. Bribing congress is a
> tactic worthy of Microsoft, not of you. Please concentrate on making
Felix, while I respect you for your work on dietlibc, calling anything that
is not written in hardcore C 'revolting' is missing the point.
> The more of your mails about CML I see, the more I am disgusted with it.
And the world yawns. We do not care for (your) religious beliefs, we care
*for facts*. Religion has no place in technology.
If you have an opinion, voice it without referring to how a program makes
*you* feel. Voice it by stating how it should make everybody feel, based on
technical arguments.
So I could say that I find your attitude disgusting, and I do, but that's
not helping anybody. So instead I'll state that your arguments are
counterproductive because they are only valid in the belief system of Felix
von Leitner, and make no sense to others with differing belief systems.
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
On Sat, 16 Feb 2002, Alexander Viro wrote:
> How does it work? Simple - look at the path from original
> tree to tree with your modifications. And no, "one big jump" doesn't
> count. Think of the way your ideas can be split into parts.
At least the rule base change from imperative -> inferential seems to
necessarily entail a single very large atomic change, given the arch-wide
rules present in the rulebase. This is the heart of the thing, and
ignoring for a moment Alan's claim that it's unnecessary, it's not at all
obvious that there's an incremental approach here. Any hints?
Hanging off the translation are things like the interpreter for the new
language bringing it up to parity with the old interpreter, which is a
meaningless delta by itself, but without which the core change is useless.
The orthogonal changes are relatively minor.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
The amount of whining I've had to read today on this topic just astonishes
me. People, please - devote 1/10th of the energy to helping esr finish and
fix CML2 to meet Linus' expectations. Face the fact: CML1 was good for
it's time, but that time is now gone.
If you spent as much time helping to get CML2 up and going as some of you
have trying to kill it (while not offering anything constructive to replace
it) it would have been DONE 6 months ago.
Sometimes, this list is worse than the proverbial sewing circle.
> > As a result, I had to tell Marcelo I had no choice but to drop
maintaining
> > the 2.4 help file. The divergence, and the damage, is probably not
> > recoverable.
>
> Divergence and damage to a configure help file ?
>
> As someone who professes to be well-versed in social systems and their
> associated mechanics, I am sure you understand the notions of social
> contracts and the like. Thus, if we, as the developers who actually
> look at the Config.help, drop the changes then that is our problem. And
> if we don't care, then there must be nothing to care about.
>
> If Marcelo and Linus are not begging for Configure.help updates (like I
> beg for SCSI layer rewrites) then there is a reason.
>
> Robert Love
>
> -
> 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/
>
Hi!
> >>. A Microsoft engineer wrote scripts/Configure. For three years, I have
> >> lived in fear that Microsoft would notice this fact and use it to attack
> >> Linux through public relations channels or legal means. They haven't
> >> yet,
> >> so I have been wrong so far.
> >>
> >
> >Teehee. I don't think you have anything to worry about, Microsoft would be
> >incredibly embarassed to admit they're contributing to 'problem number 1'.
>
>
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
>
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker
FSF is actually doing something completely different, they want to be
able to change copyrights.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa