In article <[EMAIL PROTECTED]> you wrote:
> On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
>> distributions). 18 months is more realistic for it to be deployed
>> widely enough.
> People who are going to be savvy enough to install a development 2.5.*
> kernel that is defining a
Brent D. Norris <[EMAIL PROTECTED]>:
> didn't Eric say that this has stalled though? Is that not the case?
Nope. Greg is still working. He got the first version of the theorem prover
working recently.
--
http://www.tuxedo.org/~esr/;>Eric S. Raymond
A wise and frugal
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
> Not only that, but Alan said that somebody is rewriting it in C.
I'll believe it when I see it.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work
> On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
> > Not only that, but Alan said that somebody is rewriting it in C.
> I'll believe it when I see it.
and if not then obviously nobody hates the python one enough ;)
-
To unsubscribe from this list: send the line "unsubscribe
> #2 is fixed by rewriting tools in C
didn't Eric say that this has stalled though? Is that not the case?
Brent Norris
Executive Advisor -- WKU-Linux
System Administrator -- WKU-Center for Biodiversity
Best Mechanical
-
To unsubscribe from this list: send the line
Tom Rini <[EMAIL PROTECTED]>:
> python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
> uses undocumented things which did work in python1.5.x.
That's true of the core language. The reason I moved to 2.0 was that there
are library changes in 2.0 that enabled me to to cut
On Monday 21 May 2001 10:01, Tom Rini wrote:
> On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote:
> > On Monday 21 May 2001 09:36, Tom Rini wrote:
> > > Which brings up another point, RedHat (7.1?) and Debian/woody both have
> > > the option of having python2 around. Anyone know about
On 21 May 2001, Wichert Akkerman wrote:
> In article <[EMAIL PROTECTED]>,
> Mike A. Harris <[EMAIL PROTECTED]> wrote:
> >For the record, the kgcc "mess" you speak of was used by
> >Conectiva, and I believe also by debian
>
> Debian never had that mess.
I think that Mike refers to gcc272
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote:
> > "Jakob" == Jakob ?stergaard <[EMAIL PROTECTED]> writes:
>
> Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> >> I think this is a very important point, and one I agree with. I
> >> tend to let my
> Mike A. Harris <[EMAIL PROTECTED]> wrote:
> >For the record, the kgcc "mess" you speak of was used by
> >Conectiva, and I believe also by debian
> Debian never had that mess.
Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of
them
-
To unsubscribe from this list:
In article <[EMAIL PROTECTED]>,
Mike A. Harris <[EMAIL PROTECTED]> wrote:
>For the record, the kgcc "mess" you speak of was used by
>Conectiva, and I believe also by debian
Debian never had that mess.
Wichert.
--
_
/
> i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95,
> gcc-2.91 etc. what is the cml2 parser going to do? search for my python2
This isnt a CML2 related problem.
Problem 1:
People who don't like the CML2 description
Problem 2:
People who don't like python
On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote:
> On 20 May 2001, Robert M. Love wrote:
>>(on another note, about the coexist issue: am i going to have a python
>>and python2 binary? so now the config tool will find which to use, ala
>>the kgcc mess? great)
>
> For the record, the kgcc
> "Ben" == Ben Ford <[EMAIL PROTECTED]> writes:
Ben> Mike Castle wrote:
>> People who are going to be savvy enough to install a development
>> 2.5.* kernel that is defining a new configuration utility are going
>> to be savvy enough to install python.
>>
Ben> Not only that, but Alan said
Mike Castle wrote:
>On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
>
>>distributions). 18 months is more realistic for it to be deployed
>>widely enough.
>>
>
>People who are going to be savvy enough to install a development 2.5.*
>kernel that is defining a new configuration
Mike Castle wrote:
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
distributions). 18 months is more realistic for it to be deployed
widely enough.
People who are going to be savvy enough to install a development 2.5.*
kernel that is defining a new configuration utility are
Ben == Ben Ford [EMAIL PROTECTED] writes:
Ben Mike Castle wrote:
People who are going to be savvy enough to install a development
2.5.* kernel that is defining a new configuration utility are going
to be savvy enough to install python.
Ben Not only that, but Alan said that somebody is
In article [EMAIL PROTECTED],
Mike A. Harris [EMAIL PROTECTED] wrote:
For the record, the kgcc mess you speak of was used by
Conectiva, and I believe also by debian
Debian never had that mess.
Wichert.
--
_
/ Nothing is
On 21 May 2001, Wichert Akkerman wrote:
In article [EMAIL PROTECTED],
Mike A. Harris [EMAIL PROTECTED] wrote:
For the record, the kgcc mess you speak of was used by
Conectiva, and I believe also by debian
Debian never had that mess.
I think that Mike refers to gcc272 being used as a
On Monday 21 May 2001 10:01, Tom Rini wrote:
On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote:
On Monday 21 May 2001 09:36, Tom Rini wrote:
Which brings up another point, RedHat (7.1?) and Debian/woody both have
the option of having python2 around. Anyone know about mandrake?
Tom Rini [EMAIL PROTECTED]:
python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
uses undocumented things which did work in python1.5.x.
That's true of the core language. The reason I moved to 2.0 was that there
are library changes in 2.0 that enabled me to to cut CML2's
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
Not only that, but Alan said that somebody is rewriting it in C.
I'll believe it when I see it.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work
In article [EMAIL PROTECTED] you wrote:
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
distributions). 18 months is more realistic for it to be deployed
widely enough.
People who are going to be savvy enough to install a development 2.5.*
kernel that is defining a new
Brent D. Norris [EMAIL PROTECTED]:
didn't Eric say that this has stalled though? Is that not the case?
Nope. Greg is still working. He got the first version of the theorem prover
working recently.
--
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a
A wise and frugal
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote:
Jakob == Jakob ?stergaard [EMAIL PROTECTED] writes:
Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
I think this is a very important point, and one I agree with. I
tend to let my distribution handle
Mike A. Harris [EMAIL PROTECTED] wrote:
For the record, the kgcc mess you speak of was used by
Conectiva, and I believe also by debian
Debian never had that mess.
Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of
them
-
To unsubscribe from this list: send the line
#2 is fixed by rewriting tools in C
didn't Eric say that this has stalled though? Is that not the case?
Brent Norris
Executive Advisor -- WKU-Linux
System Administrator -- WKU-Center for Biodiversity
Best Mechanical
-
To unsubscribe from this list: send the line
On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote:
On 20 May 2001, Robert M. Love wrote:
(on another note, about the coexist issue: am i going to have a python
and python2 binary? so now the config tool will find which to use, ala
the kgcc mess? great)
For the record, the kgcc mess you speak
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
Not only that, but Alan said that somebody is rewriting it in C.
I'll believe it when I see it.
and if not then obviously nobody hates the python one enough ;)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95,
gcc-2.91 etc. what is the cml2 parser going to do? search for my python2
This isnt a CML2 related problem.
Problem 1:
People who don't like the CML2 description
Problem 2:
People who don't like python
On Mon, 21 May 2001, Jakob Østergaard wrote:
> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> >
> > im not installing python2 from source just so i can run some new config
> > utility.
>
> python2 will be in rawhide when 2.5 development requires it, if I'm not much
> mistaken.
On 21 May 2001, Jes Sorensen wrote:
> John> Au contraire. It is very reasonable to have both python and
> John> python2 installed. Having two different gcc versions installed
> John> is a big pain in the arse.
>
> It's not unreasonable to have both installed, it's unreasonable to
> require
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> > John> Au contraire. It is very reasonable to have both python and
> > John> python2 installed. Having two different gcc versions installed
> > John> is a big pain in the
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> John> Au contraire. It is very reasonable to have both python and
> John> python2 installed. Having two different gcc versions installed
> John> is a big pain in the arse.
>
> It's not unreasonable to have both installed, it's unreasonable
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
> distributions). 18 months is more realistic for it to be deployed
> widely enough.
People who are going to be savvy enough to install a development 2.5.*
kernel that is defining a new configuration utility are going to be savvy
> "John" == John Cowan <[EMAIL PROTECTED]> writes:
John> Jes Sorensen wrote:
>> Telling them to install an updated gcc for kernel compilation is a
>> necessary evil, which can easily be done without disturbing the
>> rest of the system. Updating the system's python installation is
>> not a
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
distributions). 18 months is more realistic for it to be deployed
widely enough.
People who are going to be savvy enough to install a development 2.5.*
kernel that is defining a new configuration utility are going to be savvy
enough
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
John Au contraire. It is very reasonable to have both python and
John python2 installed. Having two different gcc versions installed
John is a big pain in the arse.
On Mon, 21 May 2001, Jakob Østergaard wrote:
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
im not installing python2 from source just so i can run some new config
utility.
python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.
Alan
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
John Au contraire. It is very reasonable to have both python and
John python2 installed. Having two different gcc versions installed
John is a big pain in the arse.
It's not unreasonable to have both installed, it's unreasonable to
John == John Cowan [EMAIL PROTECTED] writes:
John Jes Sorensen wrote:
Telling them to install an updated gcc for kernel compilation is a
necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is
not a reasonable request.
On 21 May 2001, Jes Sorensen wrote:
John Au contraire. It is very reasonable to have both python and
John python2 installed. Having two different gcc versions installed
John is a big pain in the arse.
It's not unreasonable to have both installed, it's unreasonable to
require it.
Eric
Arjan van de Ven wrote:
>"Eric S. Raymond" wrote:
>
>>
>>an old interface in amber do anything to explore new UI possibilities?
>>
>
>kernel != GUI
>
UI != GUI
--
"One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's
alright not to know
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?
I don't know about the rest of the world, but I _much_ prefer the old
menuconfig
On 05/18/2001 at 03:56:50 PM Mike Castle <[EMAIL PROTECTED]> wrote:
>On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
>> 1. Some of us are perfectly satisfied with the existing tools and don't want
>> them to be yanked out from under us.
>
>Then stay with 2.4.x
>
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
> 1. Some of us are perfectly satisfied with the existing tools and don't want
> them to be yanked out from under us.
Then stay with 2.4.x
> 2. Some of us have no interest in Python and don't like being forced to deal
>
> On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote:
> >But the real question is whether the old tools have enough value to be
> >worth the effort. What problem are you trying to solve here?
>
> How about:
> 1. Some of us are perfectly satisfied with the existing tools and don't want
>
> But the real question is whether the old tools have enough value to be
> worth the effort. What problem are you trying to solve here?
Im just playing with ideas and writing a CML1 parser for amusement while I
ponder single pass computation of the entire dependancy graph from a CML1
rule base
Alan Cox <[EMAIL PROTECTED]>:
> Being able to turn CML2 into CML1 might be the more useful exercise.
That's...not a completely crazy idea. Hmmm...
It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it. The resulting config.in would be huge
> For CML1 and CML2 to handle the same language, we would either have
> to live with the CML1 language's limitations or retrofit the old tools
> to speak CML2 language. The chance of the latter happening is, I think
> we can agree, effectively zero.
Being able to turn CML2 into CML1 might be
Christoph Hellwig wrote:
> That's ok as long as she doesn't add backstreet boys songtexts as long as your
> signature to her mails.
In fact, they aren't so long once you cut out the repetitions.
> On the other hand she should _really_ learn how to do it - like we all did.
Hey, nothing
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <[EMAIL PROTECTED]>:
> > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > > Aunt Tillie shouldn't try to manually configure a kernel.
> >
> > Ummm, maybe Aunt Tillie wants to learn how to
> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?
Do you really believe anyone would be dumb enough to delete them out of spite
or to further your political machinations if they could both handle
In article <[EMAIL PROTECTED]> you wrote:
> On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
>> Christoph Hellwig wrote:
[my voice was snipped here]
>> Yes, I should have limited myself to pre-egcs versions.
>
> Huh?
>
> It's been possible to have multiple versions of gcc installed
On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote:
> It's been an ugly, nasty, horrible job -- *much* nastier, by an order
> of magnitude, than designing and writing the CML2 engine. Going the
> other direction would be worse. "Like chewing razor blades" is the
> simile that leaps
Arjan van de Ven <[EMAIL PROTECTED]>:
> I hereby volunteer to maintain at least make oldconfig and make config,
> and perhaps make menuconfig.
That's the easy part; the CML1 config code may be ugly and broken, but
at least it's relatively stable. What you'd also have to do is maintain an
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
> Christoph Hellwig wrote:
> Yes, I should have limited myself to pre-egcs versions.
Huh?
It's been possible to have multiple versions of gcc installed for a very
long time. At least since 2.0 came out.
Thu Dec 19 15:54:29 1991 K.
Michael Meissner <[EMAIL PROTECTED]>:
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
>
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
> all, all of us at one point in time were
Arjan van de Ven <[EMAIL PROTECTED]>:
> Right now, it's now a dropping back. You seem to take for granted that CML2
> and your python2 frontend to it are 2.5.0 material. I don't right now.
Linus is free to change his mind. Perhaps he will. But the last word I heard
from him is that CML2 goes
On 05/18/2001 at 11:45:40 AM [EMAIL PROTECTED] wrote:
>I hereby volunteer to maintain at least make oldconfig and make config,
>and perhaps make menuconfig.
THANK YOU THANK YOU THANK YOU!!! I'm quite happy with the current form of
oldconfig and menuconfig, and will continue to use them as
Michael Meissner wrote:
>
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
>
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
> all, all of us at one point in time were newbies in
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
all, all of us at one point in time were newbies in terms of configuring
kernels, etc.
--
"Eric S. Raymond" wrote:
> > It would. Because people who like the old config would continue to use the
> > old tools
>
> Excuse me?
> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?
I hereby
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Alan, it sounds very much like you just said something stupid. This
> seems sufficiently unlikely that I am shaking my head in disbelief and
> fingernailing wax out of both ears (and if you think doing both those
> things at once
Alan Cox <[EMAIL PROTECTED]>:
> > I think you're confusing a couple of different issues here, Alan. Even
> > supposing CML2 could parse CML1 rulesets, the design question about how
> > configuration *should* work (that is, what kind of user experience we
> > want to create and who we optimize
On Friday 18 May 2001 09:19, Jes Sorensen wrote:
> Replacing the code does not require changing the style of the config
> files. Thats a major problem with CML2, you introduce a new 'let me do
> everything for you' tool that relies on a programming language that is
> not being shipped by any
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
> Alan Cox <[EMAIL PROTECTED]>:
> > > I don't want to do (a); it conflicts with my design objective of
> > > simplifying configuration enough that Aunt Tillie can do it. I won't
> > > do that unless I see a strong consensus that
On Fri, 18 May 2001, Eric S. Raymond wrote:
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets. Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
>we stick to
> I think you're confusing a couple of different issues here, Alan. Even
> supposing CML2 could parse CML1 rulesets, the design question about how
> configuration *should* work (that is, what kind of user experience we
> want to create and who we optimize ruleset design for) wouldn't go away.
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
> Jes Sorensen wrote:
>
> > Telling them to install an updated gcc for kernel compilation
> > is a necessary evil, which can easily be done without disturbing the
> > rest of the system. Updating the system's python installation is not
Christoph Hellwig wrote:
> On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
>
>>Jes Sorensen wrote:
>>
>>
>>>Telling them to install an updated gcc for kernel compilation
>>>is a necessary evil, which can easily be done without disturbing the
>>>rest of the system. Updating the
Alan Cox <[EMAIL PROTECTED]>:
> > In general this is the best option, if you create a non-standard
> > configuration for machine foo then it is your problem, not everybody
> > else's.
>
> Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
> this whole discussion
Eric S. Raymond wrote:
It would. Because people who like the old config would continue to use the
old tools
Excuse me?
Do you really believe that anyone is going to maintain the CML1 tools
for as long as a nanosecond after they get dropped out of the kernel tree?
I hereby volunteer to
Michael Meissner wrote:
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
all, all of us at one point in time were newbies in terms of
On 05/18/2001 at 11:45:40 AM [EMAIL PROTECTED] wrote:
I hereby volunteer to maintain at least make oldconfig and make config,
and perhaps make menuconfig.
THANK YOU THANK YOU THANK YOU!!! I'm quite happy with the current form of
oldconfig and menuconfig, and will continue to use them as long
Arjan van de Ven [EMAIL PROTECTED]:
Right now, it's now a dropping back. You seem to take for granted that CML2
and your python2 frontend to it are 2.5.0 material. I don't right now.
Linus is free to change his mind. Perhaps he will. But the last word I heard
from him is that CML2 goes in in
On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote:
It's been an ugly, nasty, horrible job -- *much* nastier, by an order
of magnitude, than designing and writing the CML2 engine. Going the
other direction would be worse. Like chewing razor blades is the
simile that leaps to
Arjan van de Ven [EMAIL PROTECTED]:
I hereby volunteer to maintain at least make oldconfig and make config,
and perhaps make menuconfig.
That's the easy part; the CML1 config code may be ugly and broken, but
at least it's relatively stable. What you'd also have to do is maintain an
entire
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
Christoph Hellwig wrote:
Yes, I should have limited myself to pre-egcs versions.
Huh?
It's been possible to have multiple versions of gcc installed for a very
long time. At least since 2.0 came out.
Thu Dec 19 15:54:29 1991 K.
In article [EMAIL PROTECTED] you wrote:
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
Christoph Hellwig wrote:
[my voice was snipped here]
Yes, I should have limited myself to pre-egcs versions.
Huh?
It's been possible to have multiple versions of gcc installed for a very
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
1. Some of us are perfectly satisfied with the existing tools and don't want
them to be yanked out from under us.
Then stay with 2.4.x
2. Some of us have no interest in Python and don't like being forced to deal
On 05/18/2001 at 03:56:50 PM Mike Castle [EMAIL PROTECTED] wrote:
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
1. Some of us are perfectly satisfied with the existing tools and don't want
them to be yanked out from under us.
Then stay with 2.4.x
Since doing
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
Alan Cox [EMAIL PROTECTED]:
I don't want to do (a); it conflicts with my design objective of
simplifying configuration enough that Aunt Tillie can do it. I won't
do that unless I see a strong consensus that it's the only
Arjan van de Ven wrote:
Eric S. Raymond wrote:
an old interface in amber do anything to explore new UI possibilities?
kernel != GUI
UI != GUI
--
One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's
alright not to know anything. That to
For CML1 and CML2 to handle the same language, we would either have
to live with the CML1 language's limitations or retrofit the old tools
to speak CML2 language. The chance of the latter happening is, I think
we can agree, effectively zero.
Being able to turn CML2 into CML1 might be the
Alan Cox [EMAIL PROTECTED]:
In general this is the best option, if you create a non-standard
configuration for machine foo then it is your problem, not everybody
else's.
Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
this whole discussion wouldn't be
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
Alan, it sounds very much like you just said something stupid. This
seems sufficiently unlikely that I am shaking my head in disbelief and
fingernailing wax out of both ears (and if you think doing both those
things at once is
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
all, all of us at one point in time were newbies in terms of configuring
kernels, etc.
--
Christoph Hellwig wrote:
That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.
In fact, they aren't so long once you cut out the repetitions.
On the other hand she should _really_ learn how to do it - like we all did.
Hey, nothing stops
Michael Meissner [EMAIL PROTECTED]:
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
all, all of us at one point in time were newbies in
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?
I don't know about the rest of the world, but I _much_ prefer the old
menuconfig to
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
Michael Meissner [EMAIL PROTECTED]:
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a
On Fri, 18 May 2001, Eric S. Raymond wrote:
That being the case, we do face a question of design
philosophy, expressed as a policy question about how to design
rulesets. Actually two questions:
1. When we have a platform symbol for a reference design like MVME147, do
we stick to its
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote:
But the real question is whether the old tools have enough value to be
worth the effort. What problem are you trying to solve here?
How about:
1. Some of us are perfectly satisfied with the existing tools and don't want
them to
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
Jes Sorensen wrote:
Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is not a
But the real question is whether the old tools have enough value to be
worth the effort. What problem are you trying to solve here?
Im just playing with ideas and writing a CML1 parser for amusement while I
ponder single pass computation of the entire dependancy graph from a CML1
rule base 8)
On Friday 18 May 2001 09:19, Jes Sorensen wrote:
Replacing the code does not require changing the style of the config
files. Thats a major problem with CML2, you introduce a new 'let me do
everything for you' tool that relies on a programming language that is
not being shipped by any major
Alan Cox [EMAIL PROTECTED]:
I think you're confusing a couple of different issues here, Alan. Even
supposing CML2 could parse CML1 rulesets, the design question about how
configuration *should* work (that is, what kind of user experience we
want to create and who we optimize ruleset
Alan Cox [EMAIL PROTECTED]:
Being able to turn CML2 into CML1 might be the more useful exercise.
That's...not a completely crazy idea. Hmmm...
It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it. The resulting config.in would be huge
and
Do you really believe that anyone is going to maintain the CML1 tools
for as long as a nanosecond after they get dropped out of the kernel tree?
Do you really believe anyone would be dumb enough to delete them out of spite
or to further your political machinations if they could both handle the
1 - 100 of 102 matches
Mail list logo
