Google Announces Chrome For Mac and Linux Dev Builds 251
Dan Kegel (who admits to being a Chrome developer) writes to point out a post from Mike Smith and Karen Grunberg, Product Managers for Google Chrome, with some good news for non-Windows users who want to play with Chrome: "In order to get more feedback from developers, we have early developer channel versions of Google Chrome for Mac OS X and Linux (for a couple of different Linux distributions), but whatever you do, please DON'T DOWNLOAD THEM! Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software." (The announcement continues below.)
"How incomplete? So incomplete that, among other things , you won't yet be able to view YouTube videos, change your privacy settings, set your default search provider, or even print.Meanwhile, we'll get back to trying to get Google Chrome on these platforms stable enough for a beta release as soon as possible ..." The downloads are available through the Chrome developer's channel.
Re:Already have Safari, kbyethnx (Score:5, Informative)
But they aren't... SEPARATED INTO PROCESSES!
OK, seriously and drama aside, I do think that's a good idea, and it also seem to help as a way to help out with memory management. I always thought Safari sucked a lot of RAM, especially on Windows.
Works for posting to Slashdot :) (Score:5, Informative)
I just installed the .deb on this laptop, running Ubuntu 9.10 alpha. So far, seems nice and pleasant :)
I seem some rendering problems, but Hey, I blame google!
timothy
Chromium (not Google Chrome) already works nicely (Score:4, Informative)
I've been using Chromium for some time on my Eee 1000, since FireFox hangs intermittently (slow SSD, which does not like apps that write a lot of stuff).
Chromium is a pleasant experience, fast and snappy. It used to crash all the time (e.g. when doing a copy/paste) but has been improved daily, and is now stable and usable. I don't know what the Google branded version would add on top. "DON'T DOWNLOAD" sounds like reverse psychology. Definitely, download, and use if you have a machine that is a little slower than the average desktop.
Re:Works for posting to Slashdot :) (Score:5, Informative)
I've installed the DEB also (on my Ubuntu 9.04). It's pretty stable (has not crashed on me once, though neither has Firefox) and fast. However, my Firefox has close to 80 tabs open (all filled with AJAX, Flash, etc. on my slow 1.4 GHz Celeron M with 512 MB RAM), so I'm not sure how they really compare in terms of noticeable speed while browsing regularly.
Also, just realized Chrome has spell-check!
(By the way, you can upgrade to regular Jaunty. There's no need to keep the Alpha.)
Re:It's okay (Score:2, Informative)
Firefox for Linux is actually quite shitty, they haven't fixed that scrolling bug in ages.
- Posted from the x64 .deb version of Chrome, which is working suspiciously well.
Re:Still mad at Google (Score:5, Informative)
Two issues are being confused there. First, do you use a cross-platform toolkit, or do you write a true native GUI for every platform and just keep the backend in common? Google have decided to write a new GUI for every platform, and I think they are probably correct to do this. Qt (and GTK+) are cross-platform, but they are not quite native (though arguably Qt is better at this).
Once that choice is made, all you are doing is picking a toolkit for Linux. GTK+ has the advantages of being familiar to the chrome devs, matching the existing ff dependency, being the most widely-used toolkit (and therefore appearing native for the largest number of users), and being "good enough".
Re:Wha...? (Score:5, Informative)
What Works
* Almost All Websites
* Bookmark pages
* Most visited sites
* Open link in new tab
* Open new tabs
* Omnibox
* Back, Forward, Reload
* Open link in new window
* Drag a tab to make a window
* Launch new tab
* Cut, Copy, Paste
* Keyboard shortcuts
* about:version, about:dns, about:crash, about:histograms
* Find in page
* History with search
* Form Fill
* Delete Thumbnail in New Tab Page
* Window Positions Remembered
* View Source with synatx highlighting and clickable links
What Doesn't Work
* Plugins (No flash -> No youtube)
* Bookmarks Bar
* Print
* about:network, about:memory
* Web Inspector
* Input methods such as Kotoeri (Japanese)
* Preferences (Partial implementation)
* Full Screen Browsing
* Favicon (thanks brin)
Re:Chromium (not Google Chrome) already works nice (Score:4, Informative)
Most Eee PCs have two SSDs: a large, slow one and a small fast one. Firefox became a lot snappier once I moved my profile directory to the fast SSD. Obvious in retrospect, I know...
If you have >512Mb in your netbook you could do what I've done: I keep the entire profile in RAM (on a tmpfs filesystem). On bok the profile is copied in to the ram drive and on shutdown it is rsynced back to the SSD (using --inplace to reduce copy+write operations on the urlclassifier db).
OK so it lengthens boot time a little, but it isn't often the machine is properly shutdown anyway (it tends to be suspended when not in used instead) so doesn't do a full boot often.
The urlclassifier db appears to be the main culprit for the "unexpected" IO in firefox. and even with all the relevant features turned off it seems to keep updating the file. If you don't want to put your whole profile in RAM (there is the risk of losing important bookmarks and cookies and such if the machine unexpectidly loses all power including battery or if normal shutdown scripts otherwise fail to be callde) you could probably just copy this file in and replace it with a symlink.
Re:Wha...? (Score:4, Informative)
Unlike the Mac [chromium.org] version. I'm sure they'd appreciate hints on how to use SELinux/AppArmor.
Re:Works for posting to Slashdot :) (Score:2, Informative)
GP's using 9.10. It's 6 more days till Alpha 2: Karmic release schedule [ubuntu.com].
Re:Wha...? (Score:5, Informative)
I'm not current on development for the Mac, but I've heard that multiple processes can't share a single window in OS/X.
Do you happen to know how Chrome works around this, or is this not an actual limitation?
I'm not a mac dev and what i'm posting here is gleaned from several svn log entries. So it might be wrong and inaccurate :). The chrome architecture is that there is a main process which handles the UI and there is one process per site which is launched but do not handle the UI. In Mac, the one process per site works but if you open up Activity Monitor you will see that the additional processes are shown as "Not responding" though in reality they are.
What is happening here is that OS-X expects the additional processes to respond to UI events and since they don't mark them as "Not Responding". Two solutions have been proposed
1. have dummy code which responds to UI events to keep OS-X happy
2. Rip out the Cocoa code from the additional processes which will make OS-X not expect the process to respond to UI events.
Re:CPU Usage... (Score:3, Informative)
No, i think, high cpu usage in pages that have flash is accurate description. The thing is, combination of sloppy Flash Player bytecode executing in a suboptimal version of Flash Player (i. e. for Linux to name one) really sucks the juice out of the CPU and laptop batteries. I am experiencing all those things. Laptop + Linux + Flash = slow, irresponsive experience.
Perhaps a good solution would be to implement some kind of careful sandbox in which all plugins would run, but not necessarily out of security concerns only, but also resource usage. Execute code in the plugin using at most 5% (or user defined) of the CPU, introduce rules and exceptions (when playing Flash games exclusively), etc. Use server-side meta-data (annotations) to tag what runs as fast, for example ads should use a "very low resource usage cap" constraint etc.
This is not only related to Web and Flash. We really lack such a facility on client side, where users have absolutely no control how much resources the applications they use consume. All you can do is restart or throttle down the CPU by force perhaps. Of course the problem is complicated one, but I think it can be done. Am I the one to do it? Maybe, but right now i have a headache :-)
NOT amd64 (Score:5, Informative)
A friend wrote up a Gentoo ebuild for it, which I went and installed (for the amd64 version - I run an almost entirely 64 bit system). Try to run it, and got this message:
That's odd ... double check ... yes, /usr/lib64/libgconf-2.so.4 exists ... No ... they couldn't have ...
$ file /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
*facepalm*
The 64-bit Chrome is *NOT* 64-bit, and will not run on 64-bit systems which are missing a number of 32-bit libraries.
Re:Speaking of browser innovation... (Score:4, Informative)
Re:Speaking of browser innovation... (Score:3, Informative)
Re:Wha...? (Score:2, Informative)
I think the application code is in read-only or copy-on-write pages that are shared between processes. Most OS program loaders will load and link a static executable once, no matter how many processes it is loaded in. Even the different flags will just appear in program arguments (argv), usually on the stack, beneath the first stack frame, and will not affect the shared executable. That is why you need to look at the memory stats for processes with a skeptical eye, and why Chrome's memory reports in its task manager show both total and shared memory for the separate processes. Whether an OS loads a program twice, or forks a process, it will not duplicate memory pages until they need to contain different contents.
Re:Already have Safari, kbyethnx (Score:4, Informative)
But that's kind of the point. Finally, we can severely reduce memory bloat due to memory fragmentation by separating tabs into different processes.
Chrome has a higher memory footprint at first, but then as Firefox continues to use more and more RAM, Chrome's memory usage remains consistent.