We barely ended the discussion on Chrome’s sandboxing feature and how hard or easy it is to implement such functionality on Mac OS X and Linux, and we have the Chromium project releasing the first builds of Google Chrome for Linux and Mac OS X “officially”. Nightly builds for these platforms have been available since earlier this year, but this is the first time the project puts out actual releases for Mac and Linux.
Google Chrome comes in three different channels: stable, beta, and developer, with the last of those being the most unstable. The Chrome builds for Mac OS X and Linux fall into the developer category, and therefore, are quite buggy and unstable. “Whatever you do, please DON’T DOWNLOAD THEM!,” Mike Smith and Karen Grunberg, Product Managers, write on the Chromium blog, “Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software.” These builds are quite incomplete, as they don’t do Flash, you can’t change the privacy settings, set your default search provider, or print. In addition, the Linux builds do not have sandboxing.
Sadly, I don’t have a Linux installation at my disposal currently to test out the Linux variant, but I did test the Mac OS X build. The version number is 3.0.182.5, and it looks and acts like, well, Chrome. There’s really little to tell here, since if you’ve used Chrome on Windows, you’ll be able to dive right into Chrome on the Mac. I’ve loaded various pages, and haven’t yet encountered any issues, but I’m sure more prolonged usage will turn up some serious bugs. As said, several options are still missing from the dialogs, and the import feature doesn’t work either, so it’s not yet ready for general use.
Still, releasing these builds will get some more eyes on the code, which is always a good thing. It’s a sign that the Mac and Linux variants of Chrome are closing in on the stable channel, and that the day comes nearer and nearer when I can use my favourite browser on all three platforms. Joy!
I’ve been seeing Chrome runs on Windows for too long… I can’t wait to use it on Linux and/or Mac!
I am glad they are making progress.
On Vista, Chrome is what I use the most, with Safari a close second. (IE8 a distant third.)
But on Leopard, it’s now between Safari and occasionally OmniWeb. I’ll have to wait and see if Chrome can squeeze its way into regular use.
I’m wondering how long before we might see some basic benchmarks between Safari 4 Beta and Chrome (developer) on Leopard.
Even though I haven’t tried Chrome on Ubuntu yet, I’ve been using the Chromium PPA repository for a few weeks and the browser seems to be coming along nicely.
It’s incomplete and sometimes it shows a weird behavior with downloads stalling mysteriously, but performance and rendering quality are good. I’m very impressed with the development speed too.
Looking forward to it!
It works pretty nice on Kubuntu 9.04.
It’s very fast and also stable enough to use.
I think it’s a good step forward. Hope to see a fully functional version soon.
It’s _really_ really alpha on the Mac. Clearly they are going about this the right way, and taking their time. It’s the only app I’ve seen in recent history that opens without bouncing at all. Even Preview.app bounced for me. If they can keep that speed as they reach 1.0 then they may very well have found a contender for Firefox.
Oh, well, I guess I have to wait more for a Fedora version. Too lazy to compile from source.
I like Chrome but I can’t use logmein with it.
I use Srware Iron and I quite like that.
“Requires Intel Pentium 4 / Athlon 64 or later CPU, and 32 or 64 bit Ubuntu 8.04 or later, or 32 bit Debian 5.”
How about them fscktards release some .tar.gz’s like Mozilla people do?
Be carefull with your words. Will you call them fscktards at their face if they are at the front of you? Everyone seems to forget manner if talking through web now.
Back to topic. They are using deb because they want to utilize auto-update for updating chrome. From TFA: “Installing Google Chrome will add the Google repository so your system will automatically keep Chrome up to date.”
I am sure support for other distributions will come. From TFA: “Support for other Linux distributions is planned”.
I think it is a good reason to use auto-update from the start. Tgz will just add another mechanism to update, instead of using distro’s default auto-update mechanism.
Wow. It seems they really are doing this properly. Excellent.
It does mean that you can’t just convert the package to another format using a tool like alien.
Not built for PPC? Are they only planning support for intel Macs?
Oh, well, I guess I have to wait more for a Fedora version. Too lazy to compile from source.
I installed the latest nightly build from a Debian package. It is nice to see it working but don’t bother downloading for Linux yet. It is *way* too rough. Put it this way: open a new tab, load an URL, crash, reload Chrome. It would drive you mad by the end of the day. There is no possibility even a usable beta for Linux is coming out in the next couple of months. My guess, about 6 months until it is sort of usable on Linux, based on the missing functionality compared to the Windows version.
Is it me, or is the URL autocompletion feature completely broken on Linux?
For example, whenever I type “go” I get “google.com” suggested. No problems there. But as soon as I add another “o” the whole word is autocompleted automatically and whatever I add after it gets in the way. It’s a weird behavior, and it doesn’t happen just with “google.com”.
The options menu is completely blank and displays a big “TODO” message, and it doesn’t play nice with kwin (doesn’t integrate the tab bar with the window bar)–but at least kwin lets you remove the window bar. I don’t know how metacity handles that.
It’s still alphaish, and I’m still wondering how the hell are they going to deal with the window manager behavior in Linux (since there are so many window managers and it’s impossible to jump around all of them), but at least the rest works pretty well.
Edited 2009-06-06 04:04 UTC
Gee, wow, really? Could that be why there’s a big “DO NOT DOWNLOAD” message, with all kinds of warnings like “this is an alpha preview for developers”?
Were you expecting it to work correctly?
Haha, of course not. I was just asking if anyone saw the same, that’s all.
And I’m still wondering what exactly are they going to do with kwin.
Chrome uses Google’s V8 for Javascript ( http://code.google.com/p/v8/ ) which compiles Javascript to machine code. As it is a compiler which compiles straight to machine code as opposed to targeting LLVM ( http://en.wikipedia.org/wiki/LLVM ) or C, porting it to a new platform is a non-trivial task. Currently it supports only 32-bit x86 and ARM.
There is an issue on Google code for 64-bit support ( http://code.google.com/p/v8/issues/detail?id=330 ) but there is a comment on that issue saying “There is no fixed time frame for its completion at the moment.”
PPC does not even get a mention, although on the Chromium wiki ( http://code.google.com/p/chromium/wiki/MacBuildInstructions ) there is a comment “V8 does not currently support PowerPC.” which might imply that it will in the future. I doubt that PPC is a priority for Google as the vast majority of users are on 32-bit x86 (and ARM support covers phones).
Well, V8 is a JIT, so they’d have to write PPC generation code.
I used the Mac OS X version for a few minutes and here are some random impressions:
* Some interface functions still lack “teh snappy”. Creating tabs features a useless animation compared to the Windows version and there seems to be a slight lag when using the interface in general.
* V8 is blindingly fast on all known JavaScript tests (Sunspider, V8 test, Dromaeo).
* It’s more stable than the Chromium builds which were released a couple of weeks ago,
* Negative: Chrome on OS X doesn’t have to ability (yet) to run full-screen like in Windows, i.e. the tabs touching the upper border of the screen. This is one of the most ingenious interface tweeks Google came up with and I would be a sad kitten to see it gone in the OS X port due to the space being monopolized by the menu bar. In the Chrome interface context the bar is useless except for the general notification icons and I hope that Google will make it possible to run optinally (!) like the Windows version (yes, covering the mnu bar).
* Omnibar works. Hooray! But it’s still not as good in finding recent entries in the history/bookmarks as Firefox’ Smart Location Bar.
* It seems that Chrome OS X uses the same background update mechanism. I can already see flame wars erupting over Google installing “malware”.