Hi Eric :))
>(2) Requiring Python introduces another tool into the requisites list for
>kernel building.
I'm happy to see that out of your 'silly' list...
>I'm just going to say "Today's problems, today's tools."
Hey, hope that Python never gets considered a 'today's tool' or
we will end up needing 256 CPU mainframes just to issue an 'ls'
(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.
>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'. I'm pretty sure that it is compatible
with the rest of the kernel, but we should pray for it not to change.
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. Very reasonable.
>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, is that what you're trying to say?
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.
Ra?l
Ra?l N??ez de Arenas Coronado <[email protected]>:
> 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.
Fine, try to argue that with Linus. I suspect he'll decide he has better
things to think about, and ignore you.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
-- Thomas Paine
I'm just sick of people saying that python is bloated.
I've put python on my Compaq IPAQ (running linux) and with very few
amounts of tweaks it took up less 1 MB. And that's including gtk
bindings (no tk though) and just about the entire standard python
library. Someone else tried to do this with perl and they couldn't get
it under 3 MB IIRC. And IIRC, the current kernel build system requires
perl (I could be wrong, I'm just a watcher on this list, not a hacker).
So ... PYTHON IS NOT BLOATED.
Python maybe slow (when compared to C/C++ code). But that is the nature
of an interpreted language. Python's speed is on par with Perl's and
most other interpreted languages.
Anyway ... I'm done venting.
On Tue, 2001-12-04 at 13:30, Ra?lN??ez de Arenas Coronado wrote:
> Hi Eric :))
>
> >(2) Requiring Python introduces another tool into the requisites list for
> >kernel building.
>
> I'm happy to see that out of your 'silly' list...
>
> >I'm just going to say "Today's problems, today's tools."
>
> Hey, hope that Python never gets considered a 'today's tool' or
> we will end up needing 256 CPU mainframes just to issue an 'ls'
> (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.
>
> >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'. I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.
>
> 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. Very reasonable.
>
> >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, is that what you're trying to say?
>
> 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.
>
> Ra?l
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
-------------------------------
Edward Muller
Director of IS
973-715-0230 (cell)
212-487-9064 x115 (NYC)
http://www.learningpatterns.com
-------------------------------
On Tue, 2001-12-04 at 14:50, Edward Muller wrote:
> I've put python on my Compaq IPAQ (running linux) and with very few
> amounts of tweaks it took up less 1 MB. And that's including gtk
> bindings (no tk though) and just about the entire standard python
> library. Someone else tried to do this with perl and they couldn't get
> it under 3 MB IIRC. And IIRC, the current kernel build system requires
> perl (I could be wrong, I'm just a watcher on this list, not a hacker).
> So ... PYTHON IS NOT BLOATED.
No, it doesn't require Perl. Its sh along with the standard Linux
toolset. xconfig is Tk, but not binded to Perl.
Regardless, I don't look at bloat as the issue -- who configures and
compiles their kernel on an embedded device? More specifically, it is
what the kernel hackers have available and want to use that is the
requirement. This is partly why the whole "now your mom can easily
configure her kernel" is a bs argument to me. Forget my mom..._I_ want
things a certain way. My mom, if I ever forc^H^H^H^H get her to use
Linux, will surely use the distro's kernel.
Robert Love
On Tue, 2001-12-04 at 15:07, Robert Love wrote:
> On Tue, 2001-12-04 at 14:50, Edward Muller wrote:
>
> > I've put python on my Compaq IPAQ (running linux) and with very few
> > amounts of tweaks it took up less 1 MB. And that's including gtk
> > bindings (no tk though) and just about the entire standard python
> > library. Someone else tried to do this with perl and they couldn't get
> > it under 3 MB IIRC. And IIRC, the current kernel build system requires
> > perl (I could be wrong, I'm just a watcher on this list, not a hacker).
> > So ... PYTHON IS NOT BLOATED.
>
> No, it doesn't require Perl. Its sh along with the standard Linux
> toolset. xconfig is Tk, but not binded to Perl.
>
> Regardless, I don't look at bloat as the issue -- who configures and
> compiles their kernel on an embedded device? More specifically, it is
> what the kernel hackers have available and want to use that is the
> requirement. This is partly why the whole "now your mom can easily
> configure her kernel" is a bs argument to me. Forget my mom..._I_ want
> things a certain way. My mom, if I ever forc^H^H^H^H get her to use
> Linux, will surely use the distro's kernel.
>
> Robert Love
Re: Perl ...My BAD ... I though someone somewhere listed that perl was a
requirement for building the kernel, but looking at
Documentation/Changes I see I was wrong. In fact Documentation/Changes
already lists 10 necessary packages under the "Minimal Requirements"
section. Anyway ...
I've been watching the whole CML1 vs. CML2 thing over the past year or
so and I don't think it's ever been about making it easy for a
neophite(sp) to configure their kernel. It's been about the fact that
CML1 is difficult/impossible to maintain in it's current state. I think
the choice was either to fix CML1 (language and tools) or come up with
something new. ESR decided to do the later and picked a tool that he
knew could get the job done. I'd almost bet their wouldn't have been as
much fuss over it if he had chosen perl, instead of python, but that's
just me being biased and cynical (Read: Ignore the comment.)
ESR could have written the CML2 implimentation in assembler, but decided
against it for various portability, code reuse/understandability,
simplicity, etc, etc, etc, reasons (I'll let Eric list them all if he
likes).
And .. Re: configuring a kernel on an embedded device... Well a few
people do actually. :-) I haven't done a lot with my iPAQ recently, but
there were bunches of people configuring and compiling their kernel's on
their ipaq (via nfs, IBM udrive, CF card, etc) last time I was heavily
involved. I was using the iPAQ as a way to illustrate that it's (python)
not all that big and it can fit on a small, embedded device.
And I agree, your Mom, my Mom and their friends, when linux comes to
their computer will use the the kernel that distro X gave them and will
probably never, ever even worry about it. Unless people like you and me
go to their house and upgrade it for them. :-)
--
-------------------------------
Edward Muller
Director of IS
973-715-0230 (cell)
212-487-9064 x115 (NYC)
http://www.learningpatterns.com
-------------------------------
On Tue, 04 Dec 2001, Ra?lN??ez de Arenas Coronado wrote:
> 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'. I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.
You're free to prove there is a significantly leaner solution to the
tasks CML2 fulfills.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
On Tuesday 04 December 2001 01:30 pm, Ra?lN??ez de Arenas Coronado wrote:
> Hi Eric :))
>
> >(2) Requiring Python introduces another tool into the requisites list for
> >kernel building.
>
> I'm happy to see that out of your 'silly' list...
>
> >I'm just going to say "Today's problems, today's tools."
>
> Hey, hope that Python never gets considered a 'today's tool' or
> we will end up needing 256 CPU mainframes just to issue an 'ls'
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
Rob Landley <[email protected]>:
> 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...
Actually, I haven't. I have stated that I *know how* to get a net reduction,
but that I haven't done that work yet. After CML2 drops in I will do that
work.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The real point of audits is to instill fear, not to extract revenue;
the IRS aims at winning through intimidation and (thereby) getting
maximum voluntary compliance
-- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980