13 Mar 2006 (updated 13 Mar 2006 at 16:13 UTC)
»
Ekiga-2.0.0
is out ! Congrats to Damien ! Packages are available for
Fedora Core 4, and will be available for FC5 ... sometimes ...
libvirt
Slowly making progresses, next steps will be to drive
QEmu instances and switch to XML-RPC for communication with
the Xen daemon. Some serious internal code refactoring is
needed.
libxml2
Went to the W3C XML plenary two weeks ago for the XML Core working group meeting, it was nice to see again a bunch people. Standard guys are a different kind of geeks, they don't
hack code they hack specs (some do both !), and hacking the
Web and XML can be really fun (or boring :-) ! I also
went though all Coverity reports for libxml2 and libxslt,
it was a PITA mostly due to the web interface to the reports, a couple of them would really lead to runtime bugs,
but they forced me to be far more coherent about NULL
pointers handling, static analysis is good because it can
spot problem in code that your users will usually never run
into (and if they do it won't be reproduceable !) So thanks to whoever paid for getting the analysis done :-)
Could someone explain locality trade-offs to Mozilla/Firefox developpers ?
Yes this may sound like a rant, it still is a very serious issue IMHO ...
Seriously guys before trying to push your stuff as a platform, fix your code. A program which balloons to half a
gigabyte of virtual memory usage will not draw the web page
I want to see any faster. But it managed to force me to reboot
my box, linux handling of Out of Memory conditions is pathetic
(I'm told there isn't good solutions to this, maybe), so give
me my memory back when you don't need it for the
computation of said page rendering. Oh and stop using X11
memory as a long term bitmap cache, this fools nobody, this
DOES NOT HELP !
I have an http cache it's called squid and never uses
more than 5Mbytes of RAM, I don't need another disk cache
in Firefox to double I/O accesses and disk usage, I don't need
to cache pages rendering, current processors are way fast enough to redraw them instantly WHEN NOT SWAPPING ! [Thot/Amaya was perfectly capable of instant rerendering
on 10Mhz processors, large displays and complex page layouts]
For those frustrated like me by this nice looking
memory pig, here is my recipe:
$ cat ~/.mozilla/firefox/default.*/user.js
user_pref("browser.cache.memory.enable", false);
$
restart firefox, you will see the following line when loading about:config in the URL :
browser.cache.memory.enable user set boolean false
for good measure if you're using a cache like squid turn off browser.cache.disk.enable too by double clicking on the entry. It seems it make it a bit less glutton, but it still fuck with the X11 pixmap cache, X11 size still grows (and do not shrink when closing browser tabs !!!), if someone has a trick to beat gecko/mozilla/firefox in releasing the image pixmap as soon as they are not needed for display I would be very happy. An historical anectdote is that we had to phase out all the X11 terminals in the
lab when Nescape started being popular because offloading of this pixmap cache onto the server memory led them to memory exhaustion and reboot of said terminals. This behaviour has been plaguing us for way too long, can't someone fix that
code ?