On Thu, 2005-10-27 at 20:34 +0200, ext Frantisek Dufka wrote:
>
> There should be other reason for using glibc, like that it is better and
> not slower or not substantialy bigger or something like this :-) Or
> maybe you cannot compile Opera of Flash player with it. GTK and xfree
> seems to wor
Gustavo Sverzut Barbieri wrote:
Could you do some tests if basic maemo platform compiles with uclib
and how much space it saves? Both static (file size) and dynamic (apps
running).
Maybe, but not in very near future. I still haven't got the device and
when I get it I will try something easie
On 10/27/05, Frantisek Dufka <[EMAIL PROTECTED]> wrote:
> Eero Tamminen napsal(a):
> >>I know this is pretty bold comment from me but if you think 30KB is
> >>enough to break compatibility, why not to use uClibc instead of glibc or
> >>ipkg packaging system from Familiar instead of full dpkg and .d
Eero Tamminen napsal(a):
I know this is pretty bold comment from me but if you think 30KB is
enough to break compatibility, why not to use uClibc instead of glibc or
ipkg packaging system from Familiar instead of full dpkg and .deb?
Package database and tools don't consume RAM.
Well they take
Hi,
> I know this is pretty bold comment from me but if you think 30KB is
> enough to break compatibility, why not to use uClibc instead of glibc or
> ipkg packaging system from Familiar instead of full dpkg and .deb?
Package database and tools don't consume RAM.
> I know Familiar distribution
Tommi Komulainen wrote:
This message was brought to you by the performance police. The builtin
stock icons compiled in the gtk+ library are causing extra >30k dynamic
memory consumption regardless of whether they're ever used. In 770 all
icons are coming from the icon theme anyway, so this is a c
