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."
Re:I would have tried it (Score:4, Interesting)
What are those dependencies, and how are they licensed? Depending on the license, static linking could force them to open source the entire application.
This was a continuing source of irritation back when I worked on a closed source Linux app. The glibc people do not give a crap about binary-breaking changes. This resulted in us having to create multiple variants of our product to link against different versions of the runtime libs (in order to support older distros), multiplying our testing efforts by a factor of three. We desperately wanted to just link glibc statically, but that's a no-no because it's LGPL.
Re:UI responsiveness (Score:5, Interesting)
I don’t know how many times I have recommended this simple and effective solution to the XUL problem:
Just compile the damn stuff into something faster! Like a library, but a bit safer (sandboxed).
Leave the XUL files where they are, monitor them with inotify or at specific events, and re-compile them if they were changed (e.g. by installing a extension. Do not accept pre-compiled stuff in an extension. That way you still get to see all the source.
There, done. I don’t get what’s so hard about this. The whole parsing and error handling thing is already done. Just walk the tree with functions that replace the nodes with binary code or something alike. And get the dragon book if you haven’t already. :)
Re:Nothing but praise here (Score:5, Interesting)
Last I checked (two months ago?) Chrome had no ad blockng to speak of. Sure, there's AdSweep and AdBlock+, but they just hide ads with CSS, where Firefox stops the ads from ever being downloaded. When I was using Chromium regularly I ended up using Privoxy for ad blocking.
As I understood the situation at the time, this shortcoming was due to the functionality not being possible in Chrome. So, the browser from the company that sells ads has limited ad blocking functionality. Is anyone really surprised?
Chrome works great on OpenSUSE 11.2 actually! (Score:1, Interesting)
Re:Flash not working (Score:3, Interesting)
Re:Distribute glibc then ... (Score:3, Interesting)
Sorry to sound a bit "curt", but honestly, why don't you just develop your application using something like Intel's Linux compiler?
I don't see how that would solve the problem, since we'd once again have to distribute the runtime. I didn't even know that ICC supplied its own runtime -- is that even true?
We weren't trying to weasel our way around license restrictions. We would have been happy to distribute a trimmed runtime and provide source for it, had it been easy enough. I TRIED.
We made open source contributions on multiple occasions. We found bugs in FreeType, fixed them, submitted patches. We found bugs in Leptonica, fixed them, submitted patches. We made enhancements to jbig2enc which were submitted back. During my last year there we took the plunge and paid $20000 for a commercial license to use xpdf in our product. We found that the error handling wasn't quite how we liked it, so we provided Derek with some suggestions and code, which he reworked in a way he liked a bit better, and put it into xpdf. You get the picture... We were trying to make profit from OUR technology, not by screwing over open source developers. Isn't this the way everyone wants it to work? Aren't we allowed to make profit somehow?