Adrian Bunk wrote
> Tracking feature or implementation suggestions wouldn't make sense.
> Consider e.g. that there are several people on linux-kernel who often
> write what they think the kernel should do but who never write a single
> line of code themselves. There's no value in tracking such stuff.
There are designers, and there are builders.
Can you tell me who is more important?
Thanks!
--
Al
On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> Adrian Bunk wrote
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
>
> There are designers, and there are builders.
>
> Can you tell me who is more important?
That's a distinction that doesn't exist in practice:
Designing kernel features requires good knowledge of the area of the
kernel that should be changed.
IOW: If you don't have the skills to implement it yourself you don't
have the skills to do any good design.
> Thanks!
> Al
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > Adrian Bunk wrote
> >
> > > Tracking feature or implementation suggestions wouldn't make sense.
> > > Consider e.g. that there are several people on linux-kernel who often
> > > write what they think the kernel should do but who never write a
> > > single line of code themselves. There's no value in tracking such
> > > stuff.
> >
> > There are designers, and there are builders.
> >
> > Can you tell me who is more important?
>
> That's a distinction that doesn't exist in practice:
>
> Designing kernel features requires good knowledge of the area of the
> kernel that should be changed.
>
> IOW: If you don't have the skills to implement it yourself you don't
> have the skills to do any good design.
I might agree with you on this wrt hacking around the kernel, but when it
comes to introducing new subsystems, then we have a two fold situation:
1. Designing the internals of the new subsystem
2. Interfacing it with the rest of the kernel
Part 1 is completely independent of the implementation, it's part 2 that
needs intricate implementation knowledge.
We recently had an example of this: kexec based hibernation
So, what's wrong with tapping into people's design suggestions, and allowing
others to implement it?
Thanks!
--
Al
On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> Adrian Bunk wrote:
> > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > Adrian Bunk wrote
> > >
> > > > Tracking feature or implementation suggestions wouldn't make sense.
> > > > Consider e.g. that there are several people on linux-kernel who often
> > > > write what they think the kernel should do but who never write a
> > > > single line of code themselves. There's no value in tracking such
> > > > stuff.
> > >
> > > There are designers, and there are builders.
> > >
> > > Can you tell me who is more important?
> >
> > That's a distinction that doesn't exist in practice:
> >
> > Designing kernel features requires good knowledge of the area of the
> > kernel that should be changed.
> >
> > IOW: If you don't have the skills to implement it yourself you don't
> > have the skills to do any good design.
>
> I might agree with you on this wrt hacking around the kernel, but when it
> comes to introducing new subsystems, then we have a two fold situation:
>
> 1. Designing the internals of the new subsystem
> 2. Interfacing it with the rest of the kernel
>
> Part 1 is completely independent of the implementation, it's part 2 that
> needs intricate implementation knowledge.
That's a perfect approach that works NOT.
Your subsystem needs to interact with the VFS or the block layer or
whatever else parts of the kernel.
If you had ever written kernel code you would have known that your
statement wasn't true.
> We recently had an example of this: kexec based hibernation
>
> So, what's wrong with tapping into people's design suggestions, and allowing
> others to implement it?
People soon realize that you are making a fool of yourself when your
suggestions show that you don't have a clue what you are talking about.
There's nothing wrong if this is the desired effect...
> Thanks!
> Al
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 30 Aug 2007 07:31:24 +0300, Al Boldi said:
> Adrian Bunk wrote
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
>
> There are designers, and there are builders.
>
> Can you tell me who is more important?
The problem is not builders, or designers - this list has plenty of both.
What Adrian is talking about are the people who go to designers and say
"Build me something blue, with a design that doesn't work with the VFS".
Adrian Bunk wrote:
> On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> > Adrian Bunk wrote:
> > > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > > Adrian Bunk wrote
> > > >
> > > > > Tracking feature or implementation suggestions wouldn't make
> > > > > sense. Consider e.g. that there are several people on linux-kernel
> > > > > who often write what they think the kernel should do but who never
> > > > > write a single line of code themselves. There's no value in
> > > > > tracking such stuff.
> > > >
> > > > There are designers, and there are builders.
> > > >
> > > > Can you tell me who is more important?
> > >
> > > That's a distinction that doesn't exist in practice:
> > >
> > > Designing kernel features requires good knowledge of the area of the
> > > kernel that should be changed.
> > >
> > > IOW: If you don't have the skills to implement it yourself you don't
> > > have the skills to do any good design.
> >
> > I might agree with you on this wrt hacking around the kernel, but when
> > it comes to introducing new subsystems, then we have a two fold
> > situation:
> >
> > 1. Designing the internals of the new subsystem
> > 2. Interfacing it with the rest of the kernel
> >
> > Part 1 is completely independent of the implementation, it's part 2 that
> > needs intricate implementation knowledge.
>
> That's a perfect approach that works NOT.
>
> Your subsystem needs to interact with the VFS or the block layer or
> whatever else parts of the kernel.
>
> If you had ever written kernel code you would have known that your
> statement wasn't true.
>
> > We recently had an example of this: kexec based hibernation
> >
> > So, what's wrong with tapping into people's design suggestions, and
> > allowing others to implement it?
>
> People soon realize that you are making a fool of yourself when your
> suggestions show that you don't have a clue what you are talking about.
>
> There's nothing wrong if this is the desired effect...
I really didn't expect this kind of a response, but I guess when somebody
runs out of arguments, then that's probably one of the responses to expect.
Really sad.
Thanks anyway!
--
Al
> The problem is not builders, or designers - this list has plenty of both.
>
> What Adrian is talking about are the people who go to designers and say
> "Build me something blue, with a design that doesn't work with the VFS".
And the real test of whether someone is a good engineer or a dodgy
consultant then follows. The engineer says "no" the consultant says
"it'll cost ya" ;)
Humour aside don;t knock the people who have the ideas - in amongst all
the people wanting something that is insane are aluable pieces of
information if you can ever work them out - What they actually *want*
to be able to do, and sometimes ideas that are ones people used to the
technology wouldn't have - most are silly but just occasionally you get
the "that would be silly, we'd have to umm, interesting maybe we could,
I'll get back to you" type ideas.
Alan
Alan Cox wrote:
> > The problem is not builders, or designers - this list has plenty of
> > both.
> >
> > What Adrian is talking about are the people who go to designers and say
> > "Build me something blue, with a design that doesn't work with the VFS".
>
> And the real test of whether someone is a good engineer or a dodgy
> consultant then follows. The engineer says "no" the consultant says
> "it'll cost ya" ;)
And the realist may say: look there is a middle way that reduces complexity
many-folds and still gets us what we want.
> Humour aside don;t knock the people who have the ideas - in amongst all
> the people wanting something that is insane are aluable pieces of
> information if you can ever work them out - What they actually *want*
> to be able to do, and sometimes ideas that are ones people used to the
> technology wouldn't have - most are silly but just occasionally you get
> the "that would be silly, we'd have to umm, interesting maybe we could,
> I'll get back to you" type ideas.
Exactly, and that's what makes these ideas so valuable.
Thanks!
--
Al