> Matthew Brown <mbrown@smartpages.com> wrote:
>
> > 1) Linus and most of us are not being paid for this, and we are not
> > doing this to sell. There *are* only technical issues.
>
> C'mon. Linus and you are not being paid for this but there are people out
> there who make their living on selling Linux. Linux just for fun, that's
> been quite a while ago.
If you want Linus to stop doing this for fun, then start paying him
to do it. Nobody is under any obligation to code.
There are a number of commercial unices out there, where developers
don't have fun. Why make Linux like that?
> > 2) I'm sorry, but part of being a professional *is* telling the
> > customer what's good for them. It's called professional
> > integrity.
>
> As a service professional, I learnt to a) listen to the customer's wishes
> and b) not arguing against them of, and c) to talk to development if my
> product doesn't fulfil them. This is proven to work.
Sure, but unlike commercial systems here the developers have all of
the power, because no pay cheques can be withheld or jobs lost.
In other words, without meaning to seem harsh, nobody has to listen
to you talk. Nobody has to care about the customer.
Often the developers do listen, but one of the benefits of having a
dictator's fist is that you can sometimes say "NO" to bad ideas and
silly misfeatures. If you take even this small privilege away, then
what's the difference between developing for Linux and developing a
commercial/proprietary UNIX, besides the rate of pay?
> ...
It's not even clear that raw IO is the proper solution. It may have
been what some systems have implemented, but that doesn't mean it's
the only way. As I see, raw IO basically says "this problem is much
too hard so let the application figure this out". It's a cop out.
And I'm personally enjoying the discussions about alternatives such
as copyfd() or zero-copy write()/read() calls. If there is a better
solution, then it makes sense to say "NO" now to raw IO, because it
would make it harder to adopt the better solution in the future.
Plus you always have the option of creating raw IO in a new tree or
as a standalone kernel module. Other unacceptable features began in
this way (GGI, devfs, bttv, etc). After a while, some of these were
then incorporated into the official tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/