On Wed, Apr 11, 2001 at 05:46:09PM -0400, esr@thyrsus.com wrote:
> The speed problem now is in the configurator itself.
> One of my post-1.0.0 challenges is to profile and tune the configurator
> code to within an inch of its life.
Maybe you could kill two birds with one stone by calling 1.0.0 the
prototype and rewriting it in C. Not only would this improve speed
(algorithmic improvements would also be welcome...), but it would
remove the pythonic obstacle to its adoption as a standard. Many,
including me, oppose writing the standard configurator in Python. I
don't have Python installed and I'm not going to install yet another
scripting language just because ESR likes it. Yes, we know about
freeze support, but aren't convinced that it will do well at this. It
seems that a native C configurator will be both faster and more
portable (accross distributions and mindsets) than something requiring
a recent version of SuperEasyInterpretedProgrammingLanguage 2.0.
I know that you're reluctant to make the port, but you don't need to
be too shy to ask for help. Few people on this list are afraid of C.
If you're too lazy to implement CML2 in a standard, popular, robust
language, heck, tell us, and we may be able to help you out.
Sorry for the anti-Python flamage. I'm sure that it has its uses. I,
however, don't view it as appropriate for configuration of an integral
component of a GNU/Linux system. I want to make the view clear to aid
Linus with his descision and to encourage a C port of CML2, which
languages aside looks like a good format and concept BTW.
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:17 EST