is out ! Congrats to Damien ! Packages are available for Fedora Core 4, and will be available for FC5 ... sometimes ...
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.
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 falsefor 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 ?