lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46AE8D25.20602@gmail.com>
Date:	Tue, 31 Jul 2007 09:15:17 +0800
From:	Carlo Florendo <subscribermail@...il.com>
To:	Martin Steigerwald <Martin@...htvoll.de>
Cc:	ck@....kolivas.org, Satyam Sharma <satyam@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	linux-kernel@...r.kernel.org, lkml@...anurb.dk
Subject: Re: [ck] Re: Linus 2.6.23-rc1

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ