discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deferred deallocation of local objects


From: Adam Fedor
Subject: Re: deferred deallocation of local objects
Date: Tue, 14 Oct 2003 13:46:22 -0600


On Tuesday, October 14, 2003, at 10:48 AM, Chris B. Vetter wrote:

On Tue, 14 Oct 2003 12:41:11 +0900
NeXT <address@hidden> wrote:
What the... ? *BSD zealot ?

Actually, Alex is a Linux zealot, the BSD zealot would be me ;-)

FWIW, I can vouch for everything Alex said, especially the "It works on
my box"_TM and "your BSD must be broken" (with respect to the networking
stack for crying out loud!!! yea, very likely...) parts.


I don't really like to respond to rants such as this, but I think that people on the sidelines of GNUstep might get the wrong impression. Free Software projects, by their very nature, depend a certain level of user responsibility, and it's not just because they are free.

- For one, we try as much as possible to be all things to everyone. Apple engineers, for one, often have the luxury of working on the same system if not the same machine as the people who send bugs to them. Quite a lot of the bug fixes I put in, involve things that work perfectly well on any of the 3-4 machines I work on, but not on ones that have different setups. Several times I've been stumped as well by things that work fine AND conform to the written documentation that we have, but that others have problems with.

- It's not easy doing remote debugging without a lot of help from the person who is having the problem.

- The libraries (particularly gnustep-base) are in some places very complex and it's very often that even minor changes break things in other places.

I'm very reluctant to change anything of importance in the base library because of this and I think it's amazing that Richard has kept up so well with the intricacies of the library. No one else has invested the knowledge and time understanding as much as is needed to keep the base library maintained.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]