[buug] Using swap on an SSD...or not.

[Rick Moen]

I wrote:
> Quoting Nick Moffitt (nick at zork.net):
> > Rick Moen:
> > > I tried replacing /usr/lib/libgconf2-4/gconfd-2 with a zero-length
> > > file, but then Firefox issues an _error_ at startup complaining that
> > > gconf isn't working -- and, again, there's no way to disable that
> > > behaviour.
> > 
> > Have you tried symlinking it to /bin/true?
> 
> Worth a shot, thanks.  I'll give that a try, next time I restart
> Iceweasel (Firefox).

What you get is an "An error has occurred while loading or saving
configuration information for firefox-bin.  Some of your configuration
settings may not work properly." dialogue.  Selecting Details shows:

   Failed to contact configuration server; some possible causes are that
   you need to enable TCP/IP networking for ORBit, or you have stale NFS
   locks due to a system crash. See http://www.gnome.org/projects/gconf/
   for information. (Details -  2: IOR file '/tmp/gconfd-rmoen/lock/ior'
   not opened successfully, no gconfd located: No such file or directory)

(Message repeats four more times.)  Here's one of the many other people
encountering the problem:
http://www.linuxforums.org/forum/linux-applications/126396-firefox-3-problem-gconf.html

Now, zero of Firefox's functionality actually requires GNOME's gconfd 
configuration-management daemon in any way.  (It's probable that there's 
some cooperation concerning colours, keybindings, MIME-handling, "smart
bookmarks", etc., but I'm not interested.)  I'm gathering that Firefox's
developers simply decided to start feeding Firefox preferences settings
as XML data _to_ gconfd starting with the Firefox 3.0 series, and have
induced Firefox to bitch at startup time if it cannot hold a
conversation with gconfd.  Which explains why symliniking gconfd to
/bin/true doesn't suffice.

Here's the best explanation I've found:

   There *is* a gconf dependency in Firefox, but it is a "soft"
   dependency. While Firefox may not be actively using gconf2, it
   definitely now looks for and executes it if found. I found Mozilla dev
   posts that discussed having integrated Firefox with both the gconf
   (gnome config database) and gnomevfs (virtual file system) libraries. In
   the SUSE rpm, gconf2 is listed as a dependency. When either Firefox
   32-bit or 64-bit is executed, it invokes the gconf2 daemon (gconfd-2).
   On SUSE, the 32-bit looks for the file under /opt/gnome/ while the
   64-bit looks for it under /usr/lib/ (note: not /usr/lib64/). In
   Ksysguard you see gconf2 spawned by Firefox (if gconf2 is there); a few
   moments after closing Firefox gconf2 closes down. It seems it is there
   as a developer's option; on my system, the gconf database is empty, it
   is not being used for anything. This is not a SUSE-only thing. In the
   Mozilla .tar installation, having moved out the previous ~/.mozilla
   profile folder so that it gets re-created, Firefox still calls gconf2.
   There are also two libraries in the .tar that apparently are there in
   the event that gconf or gnomevfs is being used; they are in the
   /components folder as libmozgnome.so and libnkgnomevfs.so. They can be
   removed and Firefox still runs fine, but it still calls gconfd-2. So my
   specific problem was apparently caused by somehow losing a symlink
   (despite an rpm re-install of the 32-bit) from /usr/lib/ to /opt/gnome/
   where the 32-bit version, both the rpm and the Mozilla .tar, look for
   it. Adding the symlink solved the "missing gconfd-2" error.

Lots of KDE users on the Net are complaining about "crazy GNOME
dependencies" in Firefox 3.x, e.g., 
https://lists.ubuntu.com/archives/ubuntu-mozillateam-bugs/2008-June/047450.html

See also:
https://lists.linux-foundation.org/pipermail/desktop_architects/2008-July/002682.html