Slashdot Mirror
CodeWeavers Package Google Chrome For Linux and Mac
jfbilodeau writes "The fine folks at Codeweavers performed an 11 day experiment in getting Google Chrome working on Linux and Mac. Their efforts resulted in the Chromium proof of concept. 'Not only does this give Mac and Linux users a chance to see what all the hype is about, it also lets the world see just how far Wine has come and how powerful it truly can be. In just 11 days, we were able to bring a modern Windows application across to Mac and Linux.' Caveat: their implementation is free as in beer but not free as in speech."
Google's vision isn't truly understood by everyone, IMHO. Google knew that the Open Source community would fork and port Chrome anyway and that freed up time for developers to work out the system bugs and get the thing live. Releasing the source code is a redeemable action from the many gripes that flooded about Google not offering Linux or Mac support in Chrome on launch, among other things.
Now I personally would like to see a fork that would upgrade Chrome to remove any significant Windows reliance. I don't trust Microsoft to put my interests first and therefore I don't like the idea of a browser that relies so heavily on Microsoft for security.
The dangers of knowledge trigger emotional distress in human beings.
Giving Google all your data is not just for Windows users anymore!
Good job getting it to work with wine, and verily I say that wine has come a *long* way since I started using it six years ago, but we all know what we'd really like to see: a native port of the application.
I'm against picketing but I don't know how to show it.
Dangit, I wish people would stop spreading the false meme that Google Earth has anything to do with Wine! It's native!
'In just 11 days, we were able to bring a modern Windows application across to Mac and Linux.'
How long would it take to send it back?
If anyone has some free cycles, please come help get the Linux port going. There's lots to do. See http://dev.chromium.org/
Doesn't work for me. "wine ChromeSetup.exe" gives
fixme:advapi:CheckTokenMembership ((nil) 0x12a078 0x33f930) stub! fixme:process:SetProcessShutdownParameters (00000280, 00000001): partial stub. fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),6,2,(nil),64,(nil)) - stub! fixme:winhttp:WinHttpOpen ((null), 1, (null), (null), 0x0): stub
Good for Crossover!
How 'bout you actually try the Crossover packages then like you were supposed to? http://www.codeweavers.com/services/ports/chromium/
I just downloaded the Mac OS X version from the link in TFA, and am using it to submit this post. It works, although the response seems a little slow, particularly with scrolling and window resizing. The amazing thing is that I never would have known this was done under Wine -- there was nothing else to install beyond the browser package itself. Very impressive.
Your acronym is wrong. 'Thing' does not start with F.
It does if you've been drinking.
This guy's the limit!
Although predictable (they did the same with Picasa...), it's just really a hack. I mean, as good as Wine is, it will never compete with a browser which is designed to run natively on a platform. I am curious to see benchmarks on JavaScript performance and stability, for example. If Chrome wants to be a real competitor in the browser war for Macs and Linux, it can only be it with real, officially supported versions. Otherwise it's just a pointless showcase.
In case anyone is interested, the important parts of this work are available in a Free form, one way or the other. We're using a build of Wine equivalent to WineHQ of about mid week last week, along with a few patches that haven't been committed yet. I've sent along a few more details to the Wine devel mailing list.
Cheers,
Jeremy
I just posted the tips to get all of the relevant sauce . And, as another poster reports, it's been running fairly well with Wine for at least 9 days; it just took us a bit longer to get https working properly.
Cheers,
Jeremy
At least on the URL bar. I just downloaded and tried out their Linux port and the font in the URL bar looks like ass.
Case in point: http://img140.imageshack.us/my.php?image=chromeox9.jpg
Ah well. I guess it'll give me something to play with until Google puts out an official Linux build.
Well, like a lot of :) For instance it does all the multi-process and security stuff. But then it also does what a lot of Windows programs do these days and replace the standard window management stuff as well. It relies on parts of Internet Explorer as well (like the HTTP library).
Windows apps Chrome does some, uh, interesting things that you might not expect a them to do
If you want an example of the sort of fun they had making things work, the bug this patch fixes was "Chrome URL bar has a black background" yet the fix is to the low level assembly generated by Wines build process. That's because Chrome shims BeginPaint/EndPaint by patching the in-memory system DLL headers, so it can muck about with the Windows richedit control internals and the Chrome IAT patcher didn't support Borland style imports.
For a program that has such complicated interactions with the OS, and is so heavily reliant on it for functionality, 11 days is remarkably good actually. A good sign of Wines increasing maturity.
> I suspect that's par for the course for a Wine-ported app
Wine apps are/can be much better than that on Leopard. I only have one data point, but I use it _extensively_ and it works super-well. And stably. And actually, maybe even better than on Windows.
The app? ies4osx under Darwine. Specifically, I am running Internet Explorer 6.0 for web-dev testing.
The ONLY complaint I have is that it's under the "X" program, instead of it's own program, so I can't cmd-tab to it effectively. Web I'm doing web-dev, I also run Xemacs, so I have to ctrl-tab to get to IE, then cmd-tab to get to Safari and Firefox.
And it's such a small complaint that I haven't even googled for a solution yet.
Do daemons dream of electric sleep()?
Your annoyance is misplaced.
The speech/beer convention was devised as a patch for a bug in the English language. One word, "free", has two distinct meanings. Normally people deal with these cases by using context ("Some atoms are ionized but most are unionized" vs. "Plumbers in many areas are unionized") but in this case both meanings are plausible. The two types are free are distinct, software could be free in either sense, yet English (unlike most other languages) gives us only one preferred word for both meanings.
This resulted in numerous exceedingly tedious flame wars that ended, if at all, with a lame "Oh, that's not what I thought you meant--why didn't you say so in the first place?"
Clarifying which homonym is intended right up front may annoy you, but trust me, it is far, far better than the alternative.
--MarkusQ