Re: [kbuild-devel] Re: CML2 design philosophy heads-up

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

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.


Au contraire.  It is very reasonable to have both python and python2
installed.  Having two different gcc versions installed is a big pain
in the arse.

> So far I haven't heard a single
> developer say something positive about CML2, the most positive I have
> heard so far has been "whatever", "it's his choice", "I don't care",
> "I want to hack". The majority are of the "NO!" and "you got to be
> kiddin'".


Anonymized hearsay evidence is less than convincing.


> Let's just say you didn't exactly give peoiple a good impression with
> the trolling around on how everybody had to change their option names 
> and how important it was for the world.


Decidedly bad form to criticize someone for a bug (in this case,
a design bug) that's already been fixed.  If that behavior starts,
who shall escape hanging?

 
> I do not have Python2 installed and I do not plan to, if you
> change CML2 to use a reasonable programming language I might give it a
> try.


Those who don't remember the past are condemned to repeat it.

John Cowan, _novus homo_ (Latin for "upstart")

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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 needed. 

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.

I'm raising these questions now because CML2's capabilities invite 
thinking about them.  But they're independent of the underlying language.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
	-- Lazarus Long 

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

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
> > reasonable request.
> 
> 
> Au contraire.  It is very reasonable to have both python and python2
> installed.  Having two different gcc versions installed is a big pain
> in the arse.

Fump. Some distributions do even come with two gcc's out of the box.
With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
the compiler driver if you want.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

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 system's python installation is not a
>>>reasonable request.
>>>
>>
>>Au contraire.  It is very reasonable to have both python and python2
>>installed.  Having two different gcc versions installed is a big pain
>>in the arse.
>>
> 
> Fump. Some distributions do even come with two gcc's out of the box.
> With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
> the compiler driver if you want.


Yes, I should have limited myself to pre-egcs versions.

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

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

It would. Because people who like the old config would continue to use the 
old tools

Alan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Kai Germaschewski]

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 spec sheet or consider it representative of all derivatives
>    (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise.  I go for explicitness.  If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.

I believe it's important two distinguish between two things here,
auto-configuration and normal configuration.

One should take care to not mix these things up. Of course I don't know
about the specific hardware there, but I believe selecting NVME147 will
give you arch specific code which will cope with general aspects of that
board, but also for derived designs. That makes sense, and no need to
introduce different config symbols at that level.
I'd call CONFIG symbols like that basic, and they should be described by a
ruleset which ensures that building the kernel will actually work, and
that you have a chance that it even runs. (Things like a SCSI driver
requires the SCSI midlayer, etc. which would normally lead to unresolved
symbols or the inability to load the driver module into the running kernel
later).

On the other hand, for some people it would be nice to say I've got the
reference board, build the right kernel. That's okay, but it should be
another option, and rules like that should be in a separate files, so they
don't clutter up the "basic" rulesets.

So, leave the flexibility to people who need, and on top of that you can
have a mechanism which allows easier configuration for people who don't
want to care about the details.

However, more important there would be some option like "build me a kernel
for the hardware I'm currently running on" (and let the user fine tune
afterwards).

--Kai

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > 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 Right Thing.
> > 
> > Its a good way of getting the defaults right. It may also be an appropriate
> > way of guiding presentation (eg putting the stuff the ruleset says you wont
> > have under a subcategory so you would see
> > 
> > 
> > 		CPU type
> > 		Devices
> > 		blah
> > 		blah
> > 		Other Options
> > 			IDE disk
> > 			Cardbus
> 
> I want to understand what you're driving at here and I don't get it.  What's
> the referent of "Its"?  Are you saying you think Aunt Tillie's view of the
> world should guide the presentation of options?

Aunt Tillie shouldn't try to manually configure a kernel.

	Christoph

P.S. _please_ shorten your .sig
-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Steven Cole]

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 vendor nor does it look like they are
> planning to do it anytime soon. And even if they start doing so, this

Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next
point is a very good one:

> is a totally unreasonable requirement, you *must* to make it possible
> to compile kernels on older distributions without requiring people to
> update half of their system. On some architectures, the majority of
> the users are still on glibc 2.0 and other old versions of
> tools. 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. Nobody disagrees that the Makefiles needs a
> redesign, however that doesn't mean everything else has to be
> redisigned in a totally incompatible manner.

I didn't have trouble installing python 2.0 before LM 8.0 did that for me,
but I was probably just lucky.  I've seen some reports by other people who
did have difficulty upgrading python.  If the python installation difficulties
are a real obstacle, perhaps that is what needs to be fixed.

Steven

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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.
> 
> It would. Because people who like the old config would continue to use the 
> old tools

Excuse me?

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 easy try it sometime :-)).

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?

Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?

Perhaps I'm just unusually dense this morning.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

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 easy try it sometime :-)).
> 
> 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 _will_ continue to maintain mconfig (after mec stopped even before cml2).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Michael Meissner]

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.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

"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 maintain at least make oldconfig and make config, 
and perhaps make menuconfig.

 
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?

kernel != GUI

There are plenty of UI kernel configurators out there. Good ones. Bad
ones. 
LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even
think
about taking the current, very useful for advanced users, tools away
without
offering something of at least the same capabilities.

 
> Perhaps I'm just unusually dense this morning.

Given the rest of this thread, unusual is not the word that comes to my
mind
(sorry, open door and you asked for it)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wayne.Brown]

On 05/18/2001 at 11:45:40 AM arjanv@redhat.com 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 as they're
available.

Wayne

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

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 configuring

And maybe she uses KDE and clicks kkernelconfigurator for the first
steps.
And if she wants to learn, she even might stumble on the HOWTO..

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

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. Richard Pixley  (rich at cygnus.com)

        * configure: added -V for version number option.


mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> I hereby volunteer to maintain at least make oldconfig and make config, 
> and perhaps make menuconfig.

That's the easy part; the CML1 config code may be ugly and broken, but
at least it's relatively stable.  What you'd also have to do is maintain an
entire CML1 ruleset in parallel with the canonical CML2 one.  That's 
the hard part.

I've been keeping the CML2 ruleset synced with CML1 for a year now. 
It's been an ugly, nasty, horrible job -- *much* nastier, by an order
of magnitude, than designing and writing the CML2 engine.  Going the
other direction would be worse.  "Like chewing razor blades" is the
simile that leaps to mind.

(And no, dropping back to CML1 format for the masters wouldn't be an
option; it doesn't have the semantic strength to enable CML2's new
capabilities.)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

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

And you hope this will not be razorblades if Linus decides he likes CML2 ?

 
> (And no, dropping back to CML1 format for the masters wouldn't be an
> option; it doesn't have the semantic strength to enable CML2's new
> capabilities.)

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.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Michael Meissner <meissner@spectacle-pond.org>:
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
> 
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
> all, all of us at one point in time were newbies in terms of configuring
> kernels, etc.

And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
the one with the unicorn appliques and the pink scrunchies and the Back Street
Boys posters in her bedroom?

Dammit, if we're serious about empowering people with free software we can't
limit ourselves with the attitude that configuring kernels (or anything
else) is the sacred preserve of a geek elite.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The price of liberty is, always has been, and always will be blood.  The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty.  Are
you free? 
	-- Andrew Ford

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> Right now, it's now a dropping back. You seem to take for granted that CML2
> and your python2 frontend to it are 2.5.0 material. I don't right now.

Linus is free to change his mind.  Perhaps he will.  But the last word I heard
from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe.  That's the
assumption I'm operating on.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

An armed society is a polite society.  Manners are good when one 
may have to back up his acts with his life.
        -- Robert A. Heinlein, "Beyond This Horizon", 1942

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

In article <20010518101533.E10611@thune.mrc-home.com> 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
> long time.  At least since 2.0 came out.
>
> Thu Dec 19 15:54:29 1991  K. Richard Pixley  (rich at cygnus.com)
>
>         * configure: added -V for version number option.

But with at least the combination of gcc2.7.2.x and egcs1.x it did not
work for me (and others).

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> 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 same
configuration language.

CML1 has had no official maintainer for about 4 years. People contribute bits
and it works. So as it stands there would be no reason to remove it.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <meissner@spectacle-pond.org>:
> > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > > Aunt Tillie shouldn't try to manually configure a kernel.
> > 
> > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
> > all, all of us at one point in time were newbies in terms of configuring
> > kernels, etc.
> 
> And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
> the one with the unicorn appliques and the pink scrunchies and the Back Street
> Boys posters in her bedroom?

That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.

On the other hand she should _really_ learn how to do it - like we all did.

> Dammit, if we're serious about empowering people with free software we can't
> limit ourselves with the attitude that configuring kernels (or anything
> else) is the sacred preserve of a geek elite.

I see _no_ reason to give up my control for people with an attitude that
configuring kernels will not need knowledge of what one is doing.

Your point is basically:

	Lets rewrite the kernel in VBA to make every word user
	capable of driver hacking.

That doesn't work.

	Christoph
--
Auch der Dumme hat manchmal einen gescheiten Gedanken.
Er merkt es nur nicht.  -- Danny Kaye

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> That's ok as long as she doesn't add backstreet boys songtexts as long as your
> signature to her mails.

I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA
if she did

> Your point is basically:
> 	Lets rewrite the kernel in VBA to make every word user
> 	capable of driver hacking.

I think thats a bit unfair. Changing the description language so drastically
is the big problem, not the tools or its UI. Its 'and Im forking the config
language from under every other config tool including the kde work and mconfig'

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 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 same
> configuration language.

That's a big "if" which I don't think is ever going to happen.  The
CML1 and CML2 languages are nowhere near semantically equivalent.  I
know them both intimately, and bridging the gap is a much harder
problem than you seem prepared to realize.

They look closer together than they are, because you can superficially
map individual features between them (CML2 derivations look like CML1
defines, for example).  The big difference is subtler, and has to do with
the difference between a control language and a constraint language.  As
a result, there are things you can easily do in CML2 that you can't 
practically speaking do in CML1.

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.

I know you've talked about parsing CML1 into constraints with
backtracking.  Maybe you're smart enough to do that.  I'm not.  I
tried that route early on.  I predict that if you do, you'll
experience a great deal of suffering, acquire a valuable education,
and get no good result.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

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 you from buying a used front panel and toggling in
Linux in octal.  Oughta work the first time, too.

 

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> 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 more useful exercise.

Alan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Being able to turn CML2 into CML1 might be the more useful exercise.

That's...not a completely crazy idea.  Hmmm...

It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it.  The resulting config.in would be huge
and nasty, and would only work in forward sequence with no side-effect
computation, but you just might be able to get the old tools to parse it.

Again there's a technical problem with derivations.   Probably solvable.

But the real question is whether the old tools have enough value to be
worth the effort.  What problem are you trying to solve here?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wayne.Brown]

On 05/18/2001 at 02:44:07 PM esr@thyrsus.com 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 be yanked out from under us.

2.  Some of us have no interest in Python and don't like being forced to deal
      with installing/upgrading it just for CML2.



Wayne

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> On 05/18/2001 at 02:44:07 PM esr@thyrsus.com 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 be yanked out from under us.

> 2.  Some of us have no interest in Python and don't like being forced to deal
>       with installing/upgrading it just for CML2.

Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case
of bolting alternative ui's onto the parser 

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

On Fri, May 18, 2001 at 03:04:43PM -0500, Wayne.Brown@altec.com 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
>       with installing/upgrading it just for CML2.


Some don't like installing/upgrading the following just for a kernel:

gcc
binutils
modutils
mount
Not to mention netfilter.
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wayne.Brown]

On 05/18/2001 at 03:56:50 PM Mike Castle <dalgoda@ix.netcom.com> wrote:

>On Fri, May 18, 2001 at 03:04:43PM -0500, Wayne.Brown@altec.com 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 kernel upgrades is my whole reason for using the tools, that's not a
very helpful suggestion.  It's a little like saying, "If you don't like the way
the air smells, just stop breathing."

>> 2.  Some of us have no interest in Python and don't like being forced to deal
>>       with installing/upgrading it just for CML2.
>
>
>Some don't like installing/upgrading the following just for a kernel:
>
>gcc
>binutils
>modutils
>mount
>Not to mention netfilter.

I don't especially like upgrading these things, either, and don't do it unless I
absolutely have to (that's why I'm still on egcs-2.91.66), but the kernel is
important enough to be worth the trouble.  If I have to use CML2 to move into
2.5.x, then I will.  However, upgrading a programming language I don't use, just
so I can replace a perfectly good tool with one I don't want, in order to do a
job that's always been easy to accomplish with the existing tools... well, that
seems a lot like a solution in search of a problem.

Fortunately, Alan's response about someone re-writing CML2 in C offers hope for
at least part of the issue.

Wayne

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Aaron Lehmann]

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 CML2's menuconfig. While I haven't spent much time playing
with CML2, I'm familiar with cml1's tools and see no reason why they
need changes, which IMHO (so far) are detrimental.

That's not even to mention python issues, speed, or anything else.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Ben Ford]

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 me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "John" == John Cowan <jcowan@reutershealth.com> 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.

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 seems to think he can tell every distributor to ship Python2
tomorrow. Well it's a fine dream but it's not going to happen; Most
distributors do not ship new major versions of tools in their minor
number release versions. I've seen him mention the number 6 months
until everybody ships it, but a) thats not going to happen Red Hat is
currently at 7.1 (if one looks at their release history, one would say
there is a good chance there will be a 7.2) not to mention the release
rate of Debian (not sure about the current state of all other
distributions). 18 months is more realistic for it to be deployed
widely enough.

>> So far I haven't heard a single developer say something positive
>> about CML2, the most positive I have heard so far has been
>> "whatever", "it's his choice", "I don't care", "I want to
>> hack". The majority are of the "NO!" and "you got to be kiddin'".

John> Anonymized hearsay evidence is less than convincing.

Well I don't like to quote personal conversations without peoples'
approval, now both David Woodhouse and Arjan are two examples.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

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 to install python.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Robert M. Love]

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
> require it.
> 
> Eric seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen; <snip>

I think this is a very important point, and one I agree with.  I tend to
let my distribution handle stuff like python.  now, I use RedHat's
on-going devel, RawHide. it is not using python2.  in fact, since
switching to python2 may break old stuff, I don't expect python2 until
8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
al, are written in python1 and they just are not going to change on
someone's whim.

im not installing python2 from source just so i can run some new config
utility.

(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)

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jakob Østergaard]

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.
> > 
> > It's not unreasonable to have both installed, it's unreasonable to
> > require it.
> > 
> > Eric seems to think he can tell every distributor to ship Python2
> > tomorrow. Well it's a fine dream but it's not going to happen; <snip>
> 
> I think this is a very important point, and one I agree with.  I tend to
> let my distribution handle stuff like python.  now, I use RedHat's
> on-going devel, RawHide. it is not using python2.  in fact, since
> switching to python2 may break old stuff, I don't expect python2 until
> 8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
> al, are written in python1 and they just are not going to change on
> someone's whim.

2.6.0 isn't going to happen for at least a year or two.  What's the problem ?

Want 2.5.X ?  Get the tools too.

I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified.  If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ?   I'm a lot more
worried about CML2 itself than about the tools it requires   :)

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

Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution.  Nobody ships perl4 today either.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Nicolas Pitre]

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 seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen

Distributors aren't going to ship Linux 2.5.x tomorrow either.


Nicolas

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Galbraith]

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 said someone is rewriting in C, so the python2 requirement is
already becoming a non-problem.

	-Mike

(don't like requirement, but don't think it's a big hairy deal either)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike A. Harris]

On 20 May 2001, Robert M. Love wrote:

>I think this is a very important point, and one I agree with.  I tend to
>let my distribution handle stuff like python.  now, I use RedHat's
>on-going devel, RawHide. it is not using python2.  in fact, since
>switching to python2 may break old stuff, I don't expect python2 until
>8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
>al, are written in python1 and they just are not going to change on
>someone's whim.
>
>im not installing python2 from source just so i can run some new config
>utility.
>
>(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)

powertools/7.1/SRPMS/python2-2.0-3.src.rpm

For the record, the kgcc "mess" you speak of was used by
Conectiva, and I believe also by debian before adoption in Red
Hat Linux.  It was about as good a solution as one could get for
the problem that it solved - the kernel being broken and unable
to build with our gcc-2.96.  Just to head anyone off at the
pass... the kernel is fixed and now builds properly with
gcc-2.96.  Also, if anyone has any questions about gcc-2.96
please see:

http://www.bero.org/gcc296.html

----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
Microsoft Windows(tm). A 32 bit extension and graphical shell to a 16 bit 
patch to an 8 bit operating system originally coded for a 4 bit microprocessor
which was written by a 2 bit company that can't stand 1 bit of competition.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Ben Ford]

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 going to be savvy
>enough to install python.
>
>mrc
>
Not only that, but Alan said that somebody is rewriting it in C.

-- 
 "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 me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[arjan]

In article <20010520185827.B16356@thune.mrc-home.com> 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 configuration utility are going to be savvy
> enough to install python.

In the first months, yes. Once we freeze you've just lost a major part of
your testersbase...

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Ben" == Ben Ford <ben@kalifornia.com> 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 rewriting it in C.

No and yes, the Python 2 issue is not reasonable, the C version of it
is. Hopefully with a proper C version, the Python 2 dependencies will
go away completely and that part of the discussion becomes moot.

The Python 2 one is a major issue, some people compile current kernels
because thats all that exists for their hardware. Some people who are
bringing up new architectures etc. wants to be self hosting but things
like Perl and Python are not exactly the first things you build. You
may not have threads, you may not have proper math support, maybe no
shared libraries, but that wont stop you from getting
gcc/binutils/bash going. The argument I got from Eric at the 2.5
kernel summit when I first brought this up was 'just configure your
kernel on another machine and copy it over'. Thats extremely naiive,
in some cases you do not have network nor floppy. You copy your
sources over once (so you can hack on the network driver :), you don't
want to have to rip out the disk every time you need a change to the
.config because some obscure option doesn't compile and you hadn't
noticed.

It's just not that trivial.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Jakob" == Jakob Østergaard <jakob@unthought.net> 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 stuff like python.  now, I use
>> RedHat's on-going devel, RawHide. it is not using python2.  in
>> fact, since switching to python2 may break old stuff, I don't
>> expect python2 until 8.0. that wont be for 9 months.  90% of
>> RedHat's configuration tools, et al, are written in python1 and
>> they just are not going to change on someone's whim.

Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
Jakob> the problem ?

Jakob> Want 2.5.X ?  Get the tools too.

Some people grab the latest devel kernels because thats all that works
on their hardware.

Jakob> I'm in no position to push people around, but I think the
Jakob> whining about CML2 tool requirements is completely unjustified.
Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
Jakob> where would we be today ?  I'm a lot more worried about CML2
Jakob> itself than about the tools it requires :)

gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
not.

Jakob> Whether CML2 requires python2 or not, the distributions will
Jakob> change. This is not about Eric pushing something down people's
Jakob> throats. Tools evolve, and new revisions introduce
Jakob> incompatibilities, but distributions still follow the
Jakob> evolution.  Nobody ships perl4 today either.

The point is that Eric has been trying to push distributions to ship
P2.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Robert M. Love]

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 of was used by
> Conectiva, and I believe also by debian before adoption in Red
> Hat Linux.  It was about as good a solution as one could get for
> the problem that it solved - the kernel being broken and unable
> to build with our gcc-2.96.  Just to head anyone off at the
> pass... the kernel is fixed and now builds properly with
> gcc-2.96.

my view of the mess wasn't the fact RedHat used kgcc. i think that was a
good move.

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
binary because my python1 binary is my "standard" python?

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> 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

Problem 3:
	People who don't like the tool design

Problem 4:
	People who don't have python2 


#1 is the important item
#2 is fixed by rewriting tools in C
#3 is fixed by writing alternative tools using CML2 - and if you cant its a bug
   in the CML2 language
#4 is probably one for the LDPS/LSB and vendor people to discuss so we have an
official path for python2

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wichert Akkerman]

In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
Mike A. Harris <mharris@opensourceadvocate.org> 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 fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |
-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> Mike A. Harris <mharris@opensourceadvocate.org> 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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Tom Rini]

On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote:
> >>>>> "Jakob" == Jakob ?stergaard <jakob@unthought.net> 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 stuff like python.  now, I use
> >> RedHat's on-going devel, RawHide. it is not using python2.  in
> >> fact, since switching to python2 may break old stuff, I don't
> >> expect python2 until 8.0. that wont be for 9 months.  90% of
> >> RedHat's configuration tools, et al, are written in python1 and
> >> they just are not going to change on someone's whim.
> 
> Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
> Jakob> the problem ?
> 
> Jakob> Want 2.5.X ?  Get the tools too.
> 
> Some people grab the latest devel kernels because thats all that works
> on their hardware.

And they can grab the latest tools too.  Why is this a problem again?
python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
uses undocumented things which did work in python1.5.x.  But that's not as
big of a problem since they can co-exist.  Debian already does this (And thus
CML2 already deals with python2 being called 'python2') and I wouldn't be
supprised if the PowerTools python2 rpm someone pointed out makes them
co-exist as well.

Which brings up another point, RedHat (7.1?) and Debian/woody both have the
option of having python2 around.  Anyone know about mandrake?  My point is
that some dists are already dealing with python2.

> Jakob> I'm in no position to push people around, but I think the
> Jakob> whining about CML2 tool requirements is completely unjustified.
> Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
> Jakob> where would we be today ?  I'm a lot more worried about CML2
> Jakob> itself than about the tools it requires :)
> 
> gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
> not.

Well no, but python1 requires another 2k lines of python code or so.
Eric, would it be easy/possible to go back to requiring python 1.5.x for
CML2, since that is what many dists ship with?

> Jakob> Whether CML2 requires python2 or not, the distributions will
> Jakob> change. This is not about Eric pushing something down people's
> Jakob> throats. Tools evolve, and new revisions introduce
> Jakob> incompatibilities, but distributions still follow the
> Jakob> evolution.  Nobody ships perl4 today either.
> 
> The point is that Eric has been trying to push distributions to ship
> P2.

Maybe, maybe not.  Forgetting about the QA time and whatnot, there's good
odds that all of the python scripts RedHat (for example) ships will just
work with python2.  I know one of the PPC dists didn't ship with python2
(which does have a lot of python bits to it) entirely because they were
already in testing when it came out.  It's not something the distros
can switch to at a whim, but it's also something which shouldn't cause
them problems when they do.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alexander Viro]

On 21 May 2001, Wichert Akkerman wrote:

> In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
> Mike A. Harris <mharris@opensourceadvocate.org> 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 kernel compiler
for quite a while and gcc-2.95 being used the same way in -testing.

<shrug> having different compilers for kernel and userland is not
pretty, but there's no way to avoid it at some points in cycle.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Steven Cole]

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?  My
> > > point is that some dists are already dealing with python2.
> >
> > Hi Tom,
> > I use Linux-Mandrake 8.0 now, and python2 is installed by default for a
> > development workstation installation.  I asked Mandrakesoft to also
> > install the tkinter package (which was not installed by default in
> > release candidate 1), and it appeared in LM 8.0 final, so if you like to
> > use make xconfig with CML2, you can.
>
> Could you please send this to linux-kernel as well? :)

At Tom's request, posting to lkml.
Steven

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
> uses undocumented things which did work in python1.5.x.

That's true of the core language.  The reason I moved to 2.0 was that there
are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint
substantially.

> Which brings up another point, RedHat (7.1?) and Debian/woody both have the
> option of having python2 around.  Anyone know about mandrake?  My point is
> that some dists are already dealing with python2.

Yes.  By the time 2.5 forks, distros covering an estimated 85% of the market
will carry python2 binaries which the CML2 install script will find 
automatically.  By the time 2.6 forks, we're going to laugh if we ever
remember that we thought this was an issue.

> Eric, would it be easy/possible to go back to requiring python 1.5.x for
> CML2, since that is what many dists ship with?

It wouldn't be too difficult.  But it would make the code heavier, and
I'm not clear that it would make anybody happy who isn't already willing
to deal with the design concept.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The world is filled with violence. Because criminals carry guns, we
decent law-abiding citizens should also have guns. Otherwise they will
win and the decent people will lose.
        -- James Earl Jones

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Brent D. Norris]

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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

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
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> 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 ;)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Brent D. Norris <brent@biglinux.tccw.wku.edu>:
> didn't Eric say that this has stalled though?  Is that not the case?

Nope.  Greg is still working.  He got the first version of the theorem prover
working recently.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A wise and frugal government, which shall restrain men from injuring
one another, which shall leave them otherwise free to regulate their
own pursuits of industry and improvement, and shall not take from the
mouth of labor the bread it has earned. This is the sum of good
government, and all that is necessary to close the circle of our
felicities.
	-- Thomas Jefferson, in his 1801 inaugural address