linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).