Chrome On the Way For Mac and Linux 308
TornCityVenz writes "I've seen many complaints in the feedback on Slashdot every time an article on Google's Chrome browser hits; the calls for true cross platform availability have struck me as a valid complaint. So now it seems Google is answering your calls, promising in this article on CNET a deadline for Mac and Linux support." I'd really like to not care about the name of the browser I'm using, but the mental cost of switching could be high for someone used to particular Firefox extensions, unless or until they can all be expected to work seamlessly with Chrome.
If only... (Score:2, Interesting)
What's the rush? (Score:5, Interesting)
but the mental cost of switching could be high for someone used to particular Firefox extensions, unless or until they can all be expected to work seamlessly with Chrome.
What's the big rush? I tried Linux several times before I finally dual booted, then went on later to make the switch. If Chrome offers some features you find compelling, there's no reason they can't share browsing duty.
A little competition is a good thing. Though I do have to say that opening up their platform for custom user extensions was a brilliant move by Mozilla.
Why is it taking so long? (Score:5, Interesting)
Re:FireFox extensions (Score:4, Interesting)
The only reason to block ads for most people is because they are distracting. This means flash, animated gifs, and rotating scripts. If ads didn't move, there would be a much reduced need to block them. Personally I just can't read a page if something is blinking in the corner. Prior to adblock, I'd have to put pieces of paper over parts of the screen, or scroll it to hide ads. Advertisers have always lost me as customer by advertising in this way.
I don't, and I suspect most people don't, ever block text based ads. I've no problem with them. Thus Google's ads get through. Google understands that text based ads do not bug most people, hence it's always been their ideology to use them.
If adblocking of moving images is more widespread, then text based ads become the primary way of reaching customers. That's a win for everyone -- especially Google. (the only losers are low-life flash ad designers, whose unemployment is most welcome.)
Re:Why is it taking so long? (Score:4, Interesting)
I just don't understand why it is taking Google so long to release a Mac and Linux version. Can someone explain some of the technical issues that would cause such a delay? I"m just curious.
Chrome codebase is not "cross platform", in that you can't just go ahead and compile it for Linux. They are still implementing a Gtk ui - see
http://dev.chromium.org/developers/faq
Enough already... (Score:1, Interesting)
Will people stop making new browsers and just concentrate on fixing Flash? If that one problem plugin were replaced we would have much fewer problems with all of the browsers.
Re:Why bother on the Mac? (Score:1, Interesting)
A very fast javascript engine and isolating what's running in each tab would seem to be what they're bringing. But - broadly speaking - I suppose you're right, because whether those are *enough* to tempt Mac users is another question.
Safari is a very a nice browser; and those who don't mind sacrificing polish and OS integration for extensions can download Firefox. I'm not sure where Chrome fits in here at all.
Re:Why is it taking so long? (Score:5, Interesting)
Re:A firm date from Google? (Score:5, Interesting)
Well, let's not forget that Google rarely seems to advance a software "release" to anything beyond "Beta."
They did for Chrome, which is the particular piece of software we are talking about here.
Also, they are really pushing this browser, to end users. I don't think their plan is browser dominance. I think their plan is to prevent any browser from becoming too dominant.
Re:Why is it taking so long? (Score:3, Interesting)
The question is: why were the core components windows-specific?
Why couldn't they choose cross-platform components in the first place? I doubt it would complicate things much (note I'm only talking about choosing cross-platform components, not about making sure the whole thing compiles on other OSs), and they could have spared much of the later hassle of porting the core components.
Re:Market Share (Score:3, Interesting)
They made a win32 browser and they are now going to translate it to *nix. Seems like they are going to do that properly this time (unlike Picasa and, to some extend, Earth).
Re:Why is it taking so long? (Score:5, Interesting)
Every single person I know that uses Chrome switched away from Firefox.
I know that's only a few data points in the pool, but you can't deny that people who don't "get" alternate browsers will probably never change away from IE.
Re:Why is it taking so long? (Score:5, Interesting)
I recommend Windows System Programming by Hart [amazon.com] if you want to get a feeling for it. It's arguably a better (and certainly more modern) API than the classic UNIX set. I mean, fork() is a pretty weird way to create a new process, if you think about it.
This is _not_ an endorsement of the entire Windows OS, which has miles-deep layers of cruft and crap on top -- just talking about the kernel and core system services.
Re:Market Share (Score:2, Interesting)
> Not just the JavaScript engine is
> probably win32 specific
V8 was developed on ubuntu iirc ;)
Re:only IM, no video, no voice (Score:4, Interesting)
Re:Why is it taking so long? (Score:1, Interesting)
Chrome was written under the assumption that it was better to use background processes rather than background threads to perform rendering. That is a valid assumption to make under Windows, which apparently allows background tasks to draw into other tasks' windows. But under Mac OS X and every platform running X11, a task may only draw into itself, so they'll probably have to switch to threads instead of processes, and that's not a trivial change (it took years to change from the fork/exec approach of Apache 1 to the threaded approach of Apache 2, and a lot of people still haven't converted).
it's a little unclear what the market dynamics are (Score:3, Interesting)
It's true that Mozilla providing a default search engine is a service that search-engine companies find valuable. On the other hand, having a useful default search engine is also something that Mozilla's users find valuable, so Mozilla is constrained in how they can sell that particular service.
If Some Guy's Horrible Search That Doesn't Work offered Mozilla a bazillion dollars for placement as the default search engine, they would likely have to turn it down, if they wanted their users to not hate them.
Now Yahoo or Microsoft Live aren't quite Some Guy's Horrible Search, but they are different, and in many ways not quite as good, as the status quo Firefox users expect. Basically, people use and expect Google Search, and will be annoyed if they don't get it. That means that if Google were so inclined, they could probably drive a hard bargain and reduce the amount they're paying for default-search placement, and Mozilla would likely grudgingly go along with it. At the very least, I would imagine that Microsoft or Yahoo would have to offer a considerable premium over Google's offer to make it worth the negative reactions of switching to them.
Re:only IM, no video, no voice (Score:1, Interesting)
Adding support for voice and video is easy if you only care about one platform.
Adding support for voice and video is easy if you only care about one IM network.
Adding support for voice and video is easy if you don't have to interoperate with other clients, which have weird and undocumented ways of handling things.
Adding support for video and video is easy if you're writing a single monolithic application.
None of this applies to Pidgin. It has to support multiple platforms (which means lots of ways to handle input and output), multiple IM networks (which means multiple codecs, multiple container formats, and often different ways to handle trannsferring the data across the network), be able to communicate with the crazy official clients for each network (where the network protocol is basically defined as "whatever our native client does"), and has to provide all of that support in a reusable library that can be used by different IM applications, on multiple platforms.
That's bloody hard. There's a reason why most multi-network IM applications don't support voice and video, and why the only alternative IM clients that do are those that are tied to a single network, and often to a single platform.
Re:If only... (Score:3, Interesting)
Two problems with that
1) Google Talk client doesn't support AIM (even though the web version does, sigh) or the video chat. That means you wouldn't use the Google Talk client as much as you might want to
2) Pidgin crashes a fucking hell of a lot. I've never used a version that didn't blow up on exit, or nuke when a file is downloaded, or if someone messages you, or if you enable ANY plugin at all. The quality of the project is absolutely down there in the sewers, and the same bugs affect both the Linux AND Windows builds exactly the same way.
So, neither of them are any good for anything.
Re:What's the rush? (Score:3, Interesting)