Re: ideas for returning memory to the OS

* Peter Weilbacher <[email protected]> wrote:
> On 11.12.2007 16:31, Enrico Weigelt wrote:
> 
> > If an certain libc isn't yet good enough, improve *this*
> > instead of trying to work around that in individual applications.
> 
> That's a weird statement. 

No, its just a question of modularity and clear responsibilites ;-P
You can't take care of everything at the same time / within the
same project. This job is simply too large and too complex to be
done well. That's one of the major reasons why mozilla is so fat,
It's also the reason why large vertical companies are quite 
inefficient and why socialist (top-down) economy only works on 
very small scale.

> Even if Mozilla developers had such a wide influence on the libc 
> development any changes done in the library now would still take 
> years to make it to a substantial user base,

The mozilla project itself should not take any influence to other
projects like glibc. Of course, mozilla folks are welcomed to join 
these other projects, but then functioning as developers of these
projects instead of moz there.

That's the essence of modular software engineering. 
Or in business slang: "concentrate on your key competences". 

Memory management is clearly not an key competence of mozilla,
even not large parts of the mozilla platform - it's an internet
client suite, not an operating system ;-P

> and only then Mozilla apps could benefit from it.

Exactly the opposite! The current way of doing dozens of things 
(beyond the "key competences") has these effects you're describing:
The mozilla project does much, much redundant work which cannot
be used (->imported) by other (non-moz) projects.

Monolithic Xorg also suffered badly from this problem: lack of 
modularization. But we managed to split it off into lots of smaller
packages with clean dependencies, and so development, packaging
and deployment had become *much* easier and more robust.

On a qick look through the current seamonkey tree, I've seen 
at lot of bundled 3rd-party packages things which really should 
NOT belong there:

* sqlite
* morkdb 
* bdbm
* ldap-sdk
* boehm-gc
* cairo
* libjpeg
* movemail
* libbzip2
* zlib
* nsprpub
* leaky
* elf-dynstr-gc

Beyond that, there are several other parts, which could make up
their own packages: xpcom, widgets, necko, xul-engine, ...

> I'm sure Robert's
> comment was more about what to do on shorter timescale like for
> Gecko 1.9 / FF 3.

Do you have an pointer to it ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------