From: Jarek Poplawski <jarkao2@o2.pl>
To: Adrian Bunk <bunk@kernel.org>
Cc: Jens Axboe <jens.axboe@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] make I/O schedulers non-modular
Date: Tue, 27 Nov 2007 23:15:48 +0100 [thread overview]
Message-ID: <474C9714.1080308@o2.pl> (raw)
In-Reply-To: <20071127164723.GA3406@stusta.de>
Adrian Bunk wrote, On 11/27/2007 05:47 PM:
> On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote:
>> On 25-11-2007 18:22, Jens Axboe wrote:
>>> On Sun, Nov 25 2007, Adrian Bunk wrote:
>> ...
>>>> Is there any technical reason why we need 4 different schedulers at all?
>>> Until we have the perfect scheduler :-)
>> IMHO this is not enough yet. There is something called "the right
>> of choice",
>
> That's a common misconception about open source software:
>
> There is nothing like a "right of choice".
> There is a "right to change the source code".
Maybe you are right, maybe I've used wrong words... But, e.g., google
pretends to know about this first right too. And I've meant generally,
not about open software.
>
> This means you cannot demand from anyone to offer any choices, but you
> can fork the code yourself and use and distribute modified code
> containing any choices you consider reasonable.
I don't demand anything. I've only expressed my personal opinion
that usually (if possible) the choice is better than no choice.
And, since I don't know anything in open source forbiding this, I
can ask, why you demand to take away offered choices; actually, I
think it would be much easier if you could fork the other way...
>> and, it seems, things are usually far from perfect
>> where this right is not respected.
>
> That's wrong.
>
> It's actually often much worse to have different choices with different
> features and bugfixes than having one version that contains all features
> and all bugfixes.
>
It's only a part of the theory: usually it's easier to find some bugs
if there is a possibility to compare a performance with other options;
there is also kind of stimulation and flow of new ideas between them.
Otherwise it's not so hard to overlook some stagnation.
Regards,
Jarek P.
next prev parent reply other threads:[~2007-11-27 22:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-25 16:18 [2.6 patch] make I/O schedulers non-modular Adrian Bunk
2007-11-25 16:21 ` Jens Axboe
2007-11-25 16:31 ` Adrian Bunk
2007-11-25 16:45 ` Jens Axboe
2007-11-25 16:56 ` Adrian Bunk
2007-11-25 17:22 ` Jens Axboe
2007-11-26 4:57 ` Al Boldi
2007-11-26 5:12 ` Andrew Morton
2007-11-26 5:28 ` Al Boldi
2007-11-27 7:09 ` Jarek Poplawski
2007-11-27 16:47 ` Adrian Bunk
2007-11-27 22:15 ` Jarek Poplawski [this message]
2007-11-27 22:53 ` Adrian Bunk
2007-11-28 0:20 ` Jarek Poplawski
2007-11-27 23:02 ` Jarek Poplawski
2007-11-27 23:21 ` Adrian Bunk
2007-12-30 17:52 ` Jarek Poplawski
2007-11-25 23:27 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474C9714.1080308@o2.pl \
--to=jarkao2@o2.pl \
--cc=bunk@kernel.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).