APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Chrome for OS X

Google released "Developer versions" of Chrome this week. The blog headline warns "Danger: Mac and Linux builds available" and notes that many normal browser features are still missing and to expect instability.

I found Chrome on OS X to be less balky than you might expect from such warnings. I'm predisposed to cut Chrome a lot of slack because I'm so sick of Firefox giving me spinning beach balls that require me to force quit. Chrome puts each tab in a separate process; if it does run into problems only that tab should give me grief.

You can see that in this snapshot - each Chrome process here is just a tab I have open. Notice the odd "not responding" indication - in fact, these tabs were all working fine when I captured that.


Chrome in Activity monitor

At first blush, the separate process idea seems terribly wasteful. However, it's not entirely what it seems: those processes do have shared memory.

Chrome has some other ideas - the "incognito window" will surely appeal to secretive surfers and those people who still get excited about cookies.. I'm not entirely clear on why anyone else cares about this, but IE offers the same thing so there it is. Google says "For times when you want to browse in stealth mode, for example, to plan surprises like gifts or birthdays, Google Chrome offers the incognito browsing mode". Sure, that's what people use this for.

What Chrome lacks is all the useful add-ons of Firefox. As much as I hate Firefox for its insane memory usage, its moronic use of Sqlite and its rampant crashes, I find it very hard to live without some of its features and extensions. Chrome may eventually meet my needs, but it doesn't now.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Chrome for OS X - better than expected

4 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Sun Jun 7 06:02:22 2009: 6458   jtimberman

gravatar
I too am pretty tied into Firefox and a two extensions I consider essential features that all browsers should support.

Adblock+: Sorry, I am not going to click the ads anyway, why would I want to see them. No seriously, in 15 years of using the WWW, I have never clicked an advertisement on a web site.

NoScript: I get the whole debacle about NoScript "directing" people toward its own ads and ninja-blocking the Adblock that blocked them (ugh), but whatever. Its still the best security-related extension.

I've tried to use Safari on OSX and Chrome on Windows (and now OSX), but I can't hang without the Firefox extensions. I also have myopenid.com set up as an SSL certificate for authentication, so I'd have to do the certificate export dance to make it work on other browsers.

I don't run into the memory leak and non-responsive issues on Firefox that you speak of and that many other people complain about. Probably because I usually have less than a dozen tabs open, and I block Ads, JavaScript, and Flash Ads everywhere by default :-).



Sun Jun 7 06:47:37 2009: 6459   drag

gravatar

I know that for Linux when you call a fork and spawn a new process the action is COW, or copy on write. That way when you have shared resources they all share the same memory. It is only when the new tab starts generating it's own information is when it will start having a unique copy of the memory.

And that works out great for browsers. Since the only unique information for a browser tab is going to be the actual web page then your not being wasteful at all.

And starting new processes is cheap. Very quick. In fact.. Until NPTL threads came along for Linux there was essentially no difference in how Linux handled threads vs process in the kernel area.. I assume that it is somewhat similar for OS X.

With Windows, unfortunately, the act of creating a new process has a lot of overhead. It is very expensive and very slow, relatively, so for high performance most programmers are forced to adapt a threading model for application development. Which is were you get the the notion that threads are fast and processes are slow. That is only true on Windows. In Linux processes can be very fast and depending on the task at hand they are actually preferable.

For example.. if you want to build a truley scalable application then you don't want to use just threads. You would probably use a combination and then use processes mainly and use sockets as IPC. Why? Because then you can easily make the transition to running your software over clusters with TCP/IP-based IPC. If you only do multi-threading then you need to have a way to share memory over all your processes, with Linux and clustering there is currently no way to do that over a network...

The Chrome, I expect, is a offshoot of some other project originally. And it probably shows a lot about the preferred programming model for Google and their internal stuff.

And after trying Chrome on Linux it is, indeed, very fast.



Sun Jun 7 10:06:21 2009: 6461   TonyLawrence

gravatar
I had to take out NoScript - it was the source of most of my problems. Hated to do it.

Ignoring forking encourages, even requires, large monolithic programs that try to "do it all". That's almost the definition of Microsoft programming.







Tue Mar 30 20:55:23 2010: 8307   TonyLawrence

gravatar


The "not responding" issue is gone and Chrome extensions now have everything I need.

I have dropped Firefox and Safari and have been using Chrome exclusively for a week now. I don't think I'll be going back.




------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





The teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery. (Edsger W. Dijkstra)





This post tagged: