Ten Mysteries of about:config
The Firefox Web browser, built by the Mozilla Foundation and friends is a complicated piece of technology—if you care to look under the hood. It's not obvious where the hood catch is, because the surface of Firefox (its user interface) is polished up to appeal to ordinary, nontechnical end users. This article gives you a glimpse of the engine. It explains how the Mozilla about:config URL opens up a world of obscure preferences that can be used to tweak the default setup. They're an improbable collection and therein lies the beauty of Firefox if you're a grease monkey or otherwise technical. At the end you'll know a little more about Firefox, but only enough to be dangerous.
Like any Linux-friendly piece of software, Firefox responds to preset environment variables. You can, for example, set the MOZILLA_FIVE_HOME or MOZ_PLUGIN_PATH variables prior to startup. They both work like the standard PATH, so no surprises there. The per-process space available for environment variables is, however, limited, and a simple textual concatenation of attribute-value pairs is a fairly inflexible way to store data. Firefox has a large set of runtime configuration options, and the environment isn't a suitable storage area.
Firefox configuration is stored in a small attribute-type-value database called the preference system. You can see a delta of this data set in the ~/.mozilla/firefox/*/prefs.js file. That file holds only the nondefault values selected by the user. The rest of the preferences either are unstated or stated in install files that are part of the standard install. For me, they're in /local/install/firefox/defaults/pref, because /local is my playpen of choice.
For a technical person, this system is a bit problematic because the full list of preferences doesn't appear anywhere on disk, and the standard way to change those preferences is to use the Firefox User Interface, which also is incomplete. That interface provides GUI elements (buttons, fields and check boxes) for only the most basic of the preferences available. Firefox isn't trying to be Emacs, after all. The rest of the preferences have to be dug up from elsewhere.
That other place is the special string about:config, which can be typed in the Firefox Location bar where the addresses of Web sites are entered. Briefly recall the taxonomy of W3C addresses: URIs (Universal Resource Identifiers) are a special case of IRIs (International Resource Identifiers). A URI either can be a URL (a Uniform Resource Locator) or a URN ( a Uniform Resource Name). It's URLs that we see all the time. They consist of a scheme (typically http), a colon (:) and an address (x.org).
You can define your own scheme. Mozilla does that for “about”, which is used to access internal browser resources. Try about:cache, for example. The config resource is a hook into the preference system. When you type about:config, you're navigating to a local resource just as you would navigate to a Web-based resource for an HTTP-based Web page. Figure 1 shows the results of loading the about:config resource.
This preference listing is also a form. Right-click on any preference to modify it or to state a new preference. Shorten the display by entering some text in the Filter box if you want. Many Firefox extensions can provide alternate interfaces to about:config. Feel free to experiment with them.
Nothing is perfect, alas; about:config shows only preferences that already have been set or specified anywhere. It doesn't show preferences that have meaningful uses, which appear nowhere in the about:config list. To add a value for a new preference that doesn't appear, simply right-click anywhere in the main window, and select New from the context menu, then select the type of preference: string, integer or Boolean.
Without further ado, here's a tour of preferences to which the Firefox UI doesn't give you access. Some are unmasked by about:config; some are not. They're all relatively safe to experiment with. If you get into trouble, go back to about:config and unset the preference, or, in the worst case, shut down Firefox and delete the prefs.js file noted earlier. Everything said to this point also applies to other Mozilla products: the Mozilla Application Suite, Thunderbird and so on. Hesitate before deleting the Thunderbird prefs.js file. It contains important pointers to your e-mail.
Here's a simple preference to begin with. You can explicitly set the size of the memory part of Firefox's Web cache. Here's the preference, which has a type of integer:
Set it to the integral number of KB (Kilobytes) that you want as a maximum. By default, this preference is unstated and has a default value of -1, meaning “expand to fill available memory as required”. That's a little like the Linux disk buffer cache. You might not want that if you're running OpenOffice.org and Firefox simultaneously and working both applications hard. If you do change this preference, you're going the way of Mac OS 9 and lower, where each application gets an explicit memory allocation. That could be a tuning burden if you go too far with it.
The Mozilla Web cache (both memory and disk) is akin to the function of servers like Squid. That is, both types of cache are smart about the use of HTTP headers for caching purposes. If you're in control of the local Web proxy, there's probably more value in a huge Squid cache than there is in a really big local disk cache. A bigger Firefox cache still gives some performance boost though. You can alter caching use through the integer preference:
This preference affects when Firefox accesses the cache, not how the cache itself works. The cache caches Web content every opportunity it gets, but if Firefox fails to check it, such opportunities will come rarely. Set the preference to 0 for one check per URL resource per Firefox Web surfing session, 1 always to use the cache, 2 never to use the cache and 3 (the default) when the HTTP caching rules says it's a good idea to cache.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Returning Values from Bash Functions
- SuperTuxKart 0.9.2 Released
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide