[ros-kernel] Re: File system struct - ENOUGH ALREADY

[Casper H. <ch...@us...>]

> From: KJK::Hyperion <noog@li...>
> Re: File system struct - ENOUGH ALREADY  
> 2002-04-28 14:55
>
> At 18.59 28/04/2002, you wrote:
>
> Premise: I give up. Something must be terribly wrong with me. I try to
> be reasonable. I try to be understanding. I try to explain rationally
> my point of view. I try to bring real-world examples as proof of my
> design choices. 
> I try to come at compromises with your ideas. And it never works. So,
> I give up. Just do whatever you want, I won't waste my time anymore,
> because it just doesn't work. You all seem pretty smart guys, so I
> must be the problem
 
> Go ahead and be happy, the annoying troublemaker finally shut up. I'll
> never question whatever future choice of yours, this will be my last
> message

I think you give up to easily. One problem is that you are trying to
turn ReactOS itself into a POSIX environment, instead of taking
advantage of the ReactOS subsystem abillity. This is my major concern
when I happen to disagree with you. To my knowledge only two people are
working on the POSIX subsystem. You two probably have the most knowledge
of POSIX, so any design issues that only affects the POSIX subsystem and
POSIX applications, I do not (currently) care about. I may make
suggestions when I believe something could be done better, but since I'm
probably not going to implement them I won't be mad or even force you to
do it. Nor will any other developer on this list. You don't have to
implement what is suggested on this list. However, it may be that
someone disagrees with you and eventually provides a different
implementation of something you have implemented. If this is
unacceptable to you, the project coordinators may have to make a
decission about which implementation to keep.

If you think someone does not have good reasons for doing something a
specific way, then ask them to explain further. If you think you have
a better way of doing things, then prove the other developers wrong.