Re: [ck] Re: Linus 2.6.23-rc1
From: Carlo Florendo
Date: Mon Jul 30 2007 - 21:15:21 EST
Martin Steigerwald wrote:
The current kernel development process tries to pretend that there is no
human involvement. Which is plain inaccurate: It is *all* human
involvement, without a human not a single bit of kernel code would
change.
IMHO, the above statements are all plain conjectures. How could you assert
that the kernel development process is without human development?
If you've followed the list for a while, you'd realize that the list is
very human. The fact that flames fly and abound, and the fact that
individual persons tend to be very strong with respect to their opinions
indicate that there is a rather high level of human dealings that happen on
the list.
And I think you are digressing from the main issue, which is the empirical
comparison of SD vs. CFS and to determine which is best. The root of all
the scheduler fuss was the emotional reaction of SD's author on why his
scheduler began to be compared with CFS.
We obviously all saw how the particular authors tried to address the
issues. Ingo tried to address all concerns while Con simply ranted about
his scheduler being better. If this is what you think about being a bit
more human, then I think that this has no place in the lkml.
We've all heard the "show me the numbers" argument, and as far as I can
see, CFS now fairs much better than SD.
That's the issue. The best one will emerge to be at the top. From several
months of tests and improvements, it seems CFS is emerging to be the better
scheduler.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/