In article <linux.kernel.20000603154538.B28004@ummagumma>,
Tom Gilbert <gilbertt@linuxbrit.co.uk> wrote:
>* Jonathan Walther (krooger@debian.org) wrote:
>> Using Python isn't the kind of "laughing in the face of danger" they
>> admire. After all, Python is a wimpy fru-fru Object Oriented language;
>> no self respecting kernel he-man would lower himself to rely on
>> one of THOSE to compile his kernel. No sirree bob, its gotta be
>> C and gmake all the way, with possibly a bit of bash and tcl
>> thrown in.
>
>Urm. Since when was the philosophy of this group "use an inappropriate
>tool for the job because that's what Real Men Do"?
It depends on what the job is.
If the job is ``wedge Python into the kernel so it can be used as
advertising against Perl'', then, yes, Python is the ideal tool
for the job.
If the job is ``clean up the kernel configuration process'', then
it's not so clear that Python is appropriate. I am using (and
hacking as needed) a variant of mec's mconfig tool, and it is *very*
good about properly reporting bugs in the kernel configuration
scripts, and it has the decided advantages that it's written in C, it
doesn't use anything fancier than ncurses (which is already used by
menuconfig, and it's _very_ likely that you'll find ncurses as a
standard component on a Linux distribution), and it doesn't break
the entire universe and replace it with a new one that has the
reference implementation in some horrid little scripting language.
____
david parsons \bi/ I suspect that mconfig would work with real curses,
\/ but, alas, I don't have many copies of that around.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST