And you've been smoking what to come to this conclusion? My laptop's a
pentium 266, and it runs stuff just fine. (My DESKTOP is a pentium pro
180...)
You can't attack the performance of the current implementation of CML2, so
you attack python's performance generically. Makes perfect sense.
You are aware that what it's replacing in this instance is, in large part,
shell scripts? Hello?
You may also want to look at the python-SDL binding, which people have used
to write action games in python. (Really. http://www.pygame.org )
> (maybe this will not be enough if filesystem drivers are written in
> Python too. In the future, I mean...).
>
> And yes, Python is a today's problem. Fortunately, people keeps
> rewriting their Python code in true languages.
Ah, you've rediscovered nixon's silent majority, then? The mysterious "they"
who always conveniently support your arguments.
Personally, I'm re-writing other stuff in python. I'm currently working
(microscopically part-time) on a python nameserver because bind is
frightening and djbdns is annoying, and it looks like a simple one in python
should only be a few hundred lines of code.
Are you volunteering to rewrite Anaconda in C?
> >Progress happens.
>
> Python is not progress, is just bloatware. I don't think that the
> kernel *building* should be made dependant on such a fatware. And,
> how about the 'Python License'.
The most recent version of which is, I believe, GPL compatable.
> I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.
If a new vesion comes out with an unusable language the project will fork
into free and non-free versions like dozens of projects before it, several of
which ARE in the kernel. You know this, you're just ignoring it.
> And, well, Python is fatware just for me: anyway will see
> reasonable to install a 6Mb sources language just for the
> configuration of the kernel.
The sources of which already take 260 megs, not counting the space to
actually compile them or the tools needed to do so now. (And then if you
want to look at the source code to those other tools... Look at glibc ye
mighty and despair...)
> Very reasonable.
Yes.
> >If you don't like it, feel free to go back to writing Autocoder on your
> > 1401.
>
> Good policy... People who don't like Python are morons... And
> maybe those that neither use Java or C# for the kernel will be too in
> a near future,
You're confusing "writing the kernel in $LANGUAGE" with "using a tool written
in $LANGUAGE to build the kernel". Replace $LANGUAGE with C++ and go search
the archives to see this boundary previously deliniated...
> is that what you're trying to say?
Well, at least you admit you don't know. There's hope.
> Eric, I think that this is an important issue and that the
> decision about adding such a big dependence to the kernel should be
> studied with care, and not imposed.
Why start now?
The kernel tree currently uses perl and tcl/tk. Anybody remember those being
debated at length before they went in? Anybody volunteering to MAINTAIN perl
code? (A write-only language?)
Eric's stated that there's a net reduction in the number of dispirate tools
needed to configure the kernel. There's certainly less in terms of lines of
code...
Have you ever looked at the current configurator mess?
> Raúl
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/