effective communication and effective free software

Adam Jackson ajax at redhat.com
Mon Jun 13 17:35:16 UTC 2011


On 6/13/11 12:18 PM, Denys Vlasenko wrote:

> Sloppy attitude like this is the reason just about any daemon
> (more and more of which pop up like mushrooms in every new release,
> I must add) eats at least a few megabytes of RAM.

I'd have more empathy for your position if you'd made even a cursory 
investigation into what that memory was being used for.

To be clear, this is an observation about how you're presenting your 
argument.  The original post reads mostly as "this looks like it's doing 
too much, because of these things that I don't understand but I just 
_know_ they're not necessary, so obviously this is all crap and everyone 
who's working on it should be ashamed".  Even if you were right, that's 
not a tone of voice that makes people want to listen to you.

Would you rather make a good OS, or have internet arguments about why 
we're making a bad OS?

If you approach a project by saying "I've found that we're burning a lot 
of memory here, and I don't quite understand why, but it seems to be 
related to the frobnitz component", that's productive.  It shows that 
you're concerned with quality, and that you've put some effort into 
understanding how things are already structured, even if you don't have 
a solution.  It's a sign that you have some skin in the game (apologies 
if that idiom doesn't translate well).

Instead, when you say things like:

> It's quite pathetic, really. You can easily tell which software
> was developed earlier just by looking at its memory usage.

... the message is that you're not, in fact, invested, that you're 
perfectly happy to just switch back to twm because you don't need all 
that fancy stuff.  That's an individual choice you are perfectly free to 
make, of course, but this is not the list for "here's the choices I've 
made to set up my Fedora machine just the way I like it".  This is the 
list for solutions, not configurations, and not complaints.

- ajax


More information about the devel mailing list