Nov 11 2011
Jul 21 2010
How to Restore Firefox’s Missing Search Tab
After installing Google Toolbar on my Firefox (version 3.6), the Firefox search tab mysteriously disappeared. I was amazed (cannot find a better word) that the search tab cannot be found in the Firefox “Customize Toolbar”. Now the only search tab I can use is the Google Toolbar tab.
Well, admittedly Google Toolbar has a nice functions, such as Sidewiki and “Search sites you already visited”. With “Menu bar”, “Navigation toolbar”, “Bookmark toolbar” and “Google toolbar” stacking up on the top of Firefox, I’ve lost about 20% viewable space. I would rather hide the “Google toolbar” and only display it when I need to use its features.
After some googling, I found the solution. If you run into a similar problem, you need to do the following.
- Type about:config in the Firefox location bar.
- Type search in the filter.
- You need to double click “Browser.search.openintab” and set the value to “true”, see image below.
- Close and restart Firefox
- After restarting, right-click “Menu bar”, select “Customize”. In the “Customizing Toolbar” window you’ll see the “Search” tab.
- Then you can drag “Search” tab to where you want it to be.
I installed Google Toolbar for Firefox on a different computer and the problem didn’t show. So I’m very puzzled and wouldn’t speculate any conspiracy theory.
Let me know if you have similar experience.
Related posts
Aug 22 2009
Free: a new rule in the digital economy
I’ve been always fascinated by the new economics in the digital economy. The most amazing thing is that the old economical principles have to be rewritten entirely. Cases in point are the substantial startup capital, amount of physical materials, and human labor required in the old economy.
And new principles are being invented/discovered. There are quite a few of them.
After unearthed the “Long Tail’ principle, Chris Anderson just summarized another one: “Free! The Future of a Radical Price”. To prove the power of Free, he stated:
FREE will be available in all digital forms–ebook, web book, and audiobook–for free shortly after the hardcover is published on July 7th (exact dates will be announced in the posts at left as each form is released).
And he’s serious! Now the audio version is free downloadable: http://www.wired.com/techbiz/it/magazine/17-07/mf_freer
Since I spend marginal ratio of my time with paper books, I just cancelled my order from Amazon. I guess Mr. Andreson had accounted me in the small percentage. I do have his Long Tail book on my bookshelf and almost certainly will buy his future books.
You can also read his earlier article to under how the work had evolved here.
http://www.wired.com/print/techbiz/it/magazine/16-03/ff_free
Related posts
Jul 18 2009
Is the Mobile Future in Apps or Browsers?
On a post entitled “App stores are not the future, says Google“, Chris Nuttall reported
App stores do not represent the future of the mobile industry according to Google’s vice president of engineering Vic Gundotra, who maintains consumers will instead turn to web browsers to fill their information and entertainment needs. Speaking Thursday at the Mobilebeat conference in San Francisco, Gundotra said no one, including Google, is rich enough to support all of the myriad mobile platforms in existence, a circumstance that mandates a shift in thinking away from the fragmented app store model.
“What we clearly see happening is a move to incredibly powerful browsers,” Gundotra said. “Many, many applications can be delivered through the browser and what that does for our costs is stunning. We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.” Gundotra added that Apple CEO Steve Jobs proclaimed “Build for the web” with the initial launch of the iPhone, a statement that met with resistance from developers: “I think Steve really did understand that, over the long term, it would be the web, and I think that’s how things will play out.”
There’s certainly merit in Gundotra’s arguments. However, we have to remember three things:
- Mobile bandwidth is still obscenely expensive, especially when you’re roaming.
- We still live in a always-on-sometimes-connected world. Connectivity is not ubiquitous, e.g. in a plane, in a cursed building, during a hiking trip, on a fishing boat, …
- Also from the user’s perspective, their patience is relatively low while mobile and in need of information, and the latency on mobile is intrinsically long, regardless of the bandwidth.
Imagine an online dictionary in both website and app (local in the phone) formats. The iPhone Wordweb app is infinitely better than a beautiful dictionary server out on the web.
So, I’d draw a different conclusion. Unless mobile bandwidth become as cheap as the ADSL and roaming charges are bannished, there’s a very high probably that apps will beat the browsers. The pre-condition is very unlikely to change in the next 10 years.
We shall see in 5 years.
Related posts
Dec 16 2008
Speedy ride on a VPS with Lighttpd
Apache is not adequate in restricted environment
As I said earlier, on a HostIcan VPS, my applications were running unbearably slow and erratically. I was determined to get it right even with the hard RAM limitation. BTW, I found VPSLink offers the most affordable package and reliable servers, use the referral code CSR42P to get a 10% lifetime discount.
Most Wordpress blog would get an F rating on Yahoo’s YSlow, a Firefox plug-in, for having too many HTTP requests (averaging 20~30 image, CSS and Javascripts). With the loose collaboration nature of open-source development, the number of HTTP requests will only increase with more plug-in and pretty themes. The Javascript driven Web 2.0 demands even more HTTP requests.
Apache default setup performs particularly bad in such a situation. If your applications are heavily PHP based, it’s not recommended (not all PHP modules is thread-safe) to run thread-based MPM (Multi-Processing Module, such as Worker MPM). You’re left with multi-process based prefork MPM. Each prefork process can grow to 250MB using 15~70MB RAM. PHP opcode cache occupies some 64MB. 15~20 Apache processes will take up over 300MB RAM. And you want to leave room to MySQL and have spare RAM for other memory hungry scripts. Remember I only have 512MB RAM on my VPS. If Apache process runs in HTTP/1.1 keep-alive mode, the server becomes very irresponsive when there’re many concurrent accesses.
“So I’m doomed!” thought I.
Lighttpd rocks with keep-alive
It’s at those moment of desperation, I found Lighttpd (pronounced Lighty). Lighty has a single-thread asynchronous IO architecture. Because of the asynchronous nature, an idle connection does not lock down a process or a thread as in Apache. This is perfect for keep-alive connections. In fact, Lighttpd scales very well with large number of concurrent requests.
I did a little benchmarking. For a PHP/MySQL script which generates a 40KB HTML page, 50 concurrent clients ( ab –n5000 –c50 [–k] )
- Without keep-alive:
- Apache prefork MPM: 200 requests/second
- Lighttpd: 204 r/s
- With keep-alive
- Apache: 244 r/s
- Lighttpd: 256 r/s
HTTP/1.1 Keep-alive makes a 25% performance difference.
Lighty is good, leaky is bad
With Lighty in hand, it seems I found a solution. Migrating from Apache to Lighttpd is pretty simple. It’s easier to run Lighttpd as User: apache and Group: apache, so that php-cgi won’t have permission problem with the existing PHP session directory. The only problem exists with scripts that rely on .htaccess to define mod_rewrite rules, such as Wordpress. Lighty mod_rewrite rules can only be implemented in configuration file. For Wordpress, you need to define the following:
$HTTP["host"] =~ "(^|\.)MyDomain\.com$" {
server.document-root = "/var/www/html/MyDomain"
server.error-handler-404 = "/index.php"
}
My FastCGI configuration is as follows:
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/var/run/lighttpd/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi",
"bin-environment" =>
(
"PHP_FCGI_CHILDREN" => "32",
# terminate php process after the number of requests
# being processed, in case Php leaks memory
"PHP_FCGI_MAX_REQUESTS" => "1000"
),
"bin-copy-environment" => ( "PATH", "SHELL", "USER" ),
"min-procs" => 1,
"max-procs" => 1,
"max-load-per-proc" => 8,
"idle-timeout" => 50,
# Fix PATH_INFO for PHP scripts that rely on it (like Wordpress).
"broken-scriptfilename" => "enable"
) ) )
The number of php processes = max-procs * (PHP_FCGI_CHILDREN + 1).
There are max-procs watcher processes which do not handle requests and max-procs * PHP_FCGI_CHILDREN real php backends which serve requests. If you are using an opcode cache such as eAccelerator, XCache or APC it’s advisable to keep max-procs at a very low number (1 is perfectly fine) and raise PHP_FCGI_CHILDREN instead. Those opcode caches will create a separate memory space for each parent process, otherwise. If you leave max-procs at 4, you’ll end up with four separate opcode memory cache segments.
I also bumped up the APC cache size from 32MB to 64MB (apc.shm_size=64 in /etc/php.d/apc.ini) and can run 32 PHP FastCGI processes using 210MB RAM. After that, my sites are running at a lightening speed.
While everything is rosy, I was in dismay seeing Lighty bloated from 3MB to 100MB over night. Well, there’s a memory leak in Lighttpd 1.4.18. It took over a year for someone to fix it in 1.4.20. That’s probably why Redhat EL5 doesn’t include Lighty.
I took the lighttpd-1.4.20-1.fc10.src.rpm from Fedora 10 and rebuild it in Fedora 8. Now everything runs smoothly. Download the RPMs if you want.
- lighttpd-1.4.20-1.fc8.i386.rpm
- lighttpd-debuginfo-1.4.20-1.fc8.i386.rpm
- lighttpd-fastcgi-1.4.20-1.fc8.i386.rpm
- lighttpd-mod_geoip-1.4.20-1.fc8.i386.rpm
- lighttpd-mod_mysql_vhost-1.4.20-1.fc8.i386.rpm
How to enjoy this labour of love?
Looking back this quest for running busy websites on a budget VPS, it’s not an easy route. Lighty document is rather well “lighty”, in drastic contrast to Apache. Every time there’s a glitch, you have to Google for other people’s pearls of wisdom.
When I turn on Lighty RRDTool performance graphs, it is rather enjoyable knowing that my server can handle a substantial load at a fast speed.
Here’s two useful commands. To find out the RAM usage on your VPS.
- % free
Look for “-/+ buffers/cache: 179724 344740″
To find out a process sizer,
- % top -bn 1 | grep lighttpd
Read Part 1: Choose the right VPS to host your busy websites