A Mixed Review For Google Chrome On Linux 223
omlx contributes this link to LinuxCrunch's short review of Google Chrome on Linux, writing: "The summary of it is that although Google Chrome is in a beta stage, it is fast, stable, and has a simple, clean, and effective GUI design. On other side, Google Chrome has a small number of extensions, doesn't support RSS, lacks integration with KDE, and doesn't support complex scripts very well. Personally, I didn't succeed in using Flash Player on Google Chrome beta 1 (I am using OpenSUSE 11.2) and I wonder how the quality of Google Chrome OS will be, especially if it's based on Linux and Google Chrome."
Google Chrome linux (Score:4, Informative)
Long (relatively) user here. (Score:4, Informative)
Mostly good here. (Score:4, Informative)
Getting Flash to Work (Score:5, Informative)
I had two systems, both 64-bit Fedora, that I tried Chrome on. On one, Flash worked fine from the moment I installed Chrome. On the other, Chrome didn't even notice the plugin existed. Flash (32-bit, wrapped with mozilla-plugin-config) worked just fine in Firefox on both computers. When I compared the two systems, it turned out that one was missing a symbolic link. The file is in /usr/lib64/mozilla/plugins-wrapped, but Chrome was looking in /usr/lib/mozilla/plugins.
Adding a symbolic link solved it.
More info: Getting Flash to work on Google Chrome for 64-bit Linux [hyperborea.org].
Re:I would have tried it (Score:4, Informative)
The entire Chrome application is open under a BSD license. You can check out the licenses of the dependencies as well here:
http://code.google.com/chromium/terms.html [google.com]
Re:sigh (Score:5, Informative)
As far as the KDE thing, though, I agree. Exactly what sort of "integration" with KDE was expected?
I would appreciate it if Chrome took it's default font size/color from the KDE settings. What would even be better is if there was a KDE theme that also took over the KDE look and feel for the browser window and the tabs, and the buttons and dialogues that Chrome has.
Re:Nothing but praise here (Score:4, Informative)
I agree, if I even bothered to RTFA, I would have stopped reading at that point.
Re:Getting Flash to Work (Score:3, Informative)
I'm running openSUSE 11.2 64-bit. I installed the actual 64-bit Flash with 64-bit Chrome. It works well.
Fedora 11 and Flash works here... (Score:3, Informative)
Fedora 11 and Adobe Flash works here...
However, disabling IPV6 is not possible (unlike Firefox). So every access I wait for IPV6 DNS to timeout. It is really slow compared to Firefox.
Re:Not Chrome's Fault (Score:2, Informative)
Re:Nothing but praise here (Score:3, Informative)
Indeed. I also have installed it on my machine and have had no troubles. Responsiveness is slightly better than firefox, though the difference isn't as great as when I boot into Windows on the same machine where I also have Chrome and Firefox.
In the end Chrome has several good features for general browsing especially speed but lacks the extendability of Firefox. Firefox has more available features but is slower. Both are likely to improve.
Did you try the tarballs? (Score:2, Informative)
I use a Chromium nightly tarball [chromium.org] unpacked to a directory in /tmp on Slackware 13.0. It wasn't straightforward but I did get it working by copying some libraries from firefox into the same directory.
Re:Getting Flash to Work (Score:2, Informative)
Re:sigh (Score:2, Informative)
Re:Nothing but praise here (Score:1, Informative)
Re:Fedora 11 and Flash works here... (Score:4, Informative)
Uhm, if you have a criminally broken router and feel no urge to work around it, you should disable IPv6 system-wide. No program should deal with such type of configuration on its own.
And your configuration seems broken: if you don't have any IPv6 addresses better than link-local, glibc shouldn't even send AAAA queries, at least in any semi-recent version. If you have any better addresses (not necessarily globally routable), the queries will be sent but since they go exactly the same way A queries go, there's no way for A responses to come swiftly but AAAA having to timeout, save for something on the way sabotaging them and dropping them silently. And since you claim that this happens for every access, it's something near you.
Re:UI responsiveness (Score:5, Informative)
It already does. On first boot XUL / JS is parsed into objects which are serialized as prototypes into XUL.mfl where mfl stands for Mozilla Fast Load. The next time the app starts it constructs the prototypes from the fast load file rather than the XML. The mfl file is regenerated when the XUL changes of course.