New Google Apps For Linux Coming

techoon writes "The goal of the Google Linux Client Team is to develop Linux desktop applications, such as the official Linux versions of Google Earth and Google Picasa. This team made an interesting splash during a presentation at the first-ever Linux Foundation Collaboration Summit, which they had kindly hosted at their Mountain View campus. The Google presenters claimed some 'significant accomplishments' and other new Google desktop applications coming out this year for the Linux platform."

Comments

Native?

[colourmyeyes]

As TFA says, Picasa for Linux wasn't native, just a Windows version repackaged with Wine. I hope the new stuff isn't like that.

Re:Native?

[yincrash]

should they be writing picasa fom scratch? the wine versions help the wine project by submitting patches bringing more win32 apps usable to linux making linux a more and more appealing option.

Re:Native?

[colourmyeyes]

This misses the point of Wine. Wine is for running applications that CANNOT be ported, e.g. commercial software like MS Office. Applications that can be ported, should. Otherwise, they pack their own version of Wine, and it can conflict with a version of Wine a user already has installed.

A native Linux version of Picasa doesn't seem preposterous to me. Google's done it with Google Earth.

Using hacks like Wine (a great hack, but still a hack) to run applications on Linux makes it less appealing to me than running native software.

Re:Native?

[GPL Apostate]

Part of the problem is, native for which Linux? There are multiple OSes based on the Linux kernel, and they vary wildly, as to which hardware they run on and what underlying libraries and APIs they incorporate.

If Google wants to do it right, they need to release a cross-platform source tarball, and nothing less. A binary glob that only runs in version xx.xx of 'distro' xyzzy won't cut it.

Part of why I say this is that I run NetBSD, and said source tarball would be rolled into pkgsrc quickly, too. A binary blob that I have to run under Linux emulation wouldn't be nearly as nice.

Re:Native?

[larry bagina]

Google Earth! came from Keyhole and was originally written cross-platform with Qt. Picassa came from Idealabs (which is a big MS shop) and was written for Windows (there isn't a Macintosh version). Google has acquired a lot of random stuff so it's kind of a hodge podge.

Re:Native?

[kripkenstein]

This misses the point of Wine. Wine is for running applications that CANNOT be ported, e.g. commercial software like MS Office. Applications that can be ported, should.

I agree. However, if we are talking about porting by rewriting significant parts of the code, then why not do this the right way? I mean, rewrite it in a portable framework (Java, .Net/Mono, Python) using portable libraries (GTK, Qt). Then instead of porting to Linux you now have a single code base to improve upon for all of your platforms.

In fact, Google should spearhead this sort of thing by supporting (if only in the form of patches) cross-platform toolkits like Python, GTK, etc. Google's web services (search, docs&spreadsheets, etc.) are powerful in part because they are cross-platform; Google applications should be the same. To do so is in Google's self-interest.

"Some projects will be open source"

[tlevine]

Why not all? (And why no hyphen either?)

"What could this be? Google Desktop for Linux?"

[footissimo]

Ooo..I'm really looking forward to them porting that one

Re:"What could this be? Google Desktop for Linux?"

[rtb61]

Google only really makes minimal commitments to open source, really only sufficient for marketing purposes or to save itself money on licence fees. The only times you want to get into producing your own Linux distribution, is when you want to get into the service and support market upon a national or international basis (demonstrates expertise), you have a sufficient number of desktops to warrant your own corporate/government distribution (tens of thousands), high performance - high security - high stability i.e.. everything stripped out you do not need for your application.

So google might build a special distribution for it's data centre but it's desktops would be a default popular install i.e. Ubuntu as well as a few other desktops for a depth of knowledge and trialling.

Google is first and foremost a marketing company, a company that advertises itself as one of it's main priorities, any public action it's takes will be adjusted to promote a cool, friendly, feel good, image, of course anything done in private (subject to employee leaks) will be purely profit based, all rather smarmy. There is no marketing value in google creating it's own Linux desktop (if it creates a privacy invasive version to generate profits it would simply get caught and suffer the consequences), whilst there is marketing value in creating applications to run properly on Linux, google doesn't want invest the money(it still wants the free marketing of course), and definitely not contribute to open source versions, especially when the applications have a distinct element of prying into the users private life for 'marketing' purposes.

TFA is spam??

[bcrowell]

What the heck? I clicked on the link to TFA. It sent me to a page at techrythm.com, where there is an extremely short article, giving hardly any more information than the slashdot summary. In it are a lot of links double-underlined in green. When I move my mouse over the links, I get an ad floating around. When I click on a link, I go to some lame spam page that doesn't seem to have anything to do with what the link claims it is.

Re:TFA is spam??

[Anonymous Coward]

It's a metaphor for how Google will make money from Linux users.

Re:TFA is spam??

[bcrowell]

Sorry about the reply-to-self, but considering how incredibly annoying and misleading these adbrite ads are, I thought some slashdotters might be interested to know that adding http://*.adbrite.com/* to your adblock patterns seems to get rid of them completely -- the spam links don't even show up with the double underlining, which I imagine is because they're being inserted dynamically by a JS script served up from an adbrite server.

Re:Funny enough, I just installed googleearth...

[ForumTroll]

googleearth-package is in the Debian repository and will help to quickly create the deb file for google earth. Just apt-get install googleearth-package and then run make-googleearth-package.

Give us gtalk on linux already!

[LingNoi]

Gtalk with all the features available that the windows version has, such as chat logging and voicemail support. If there was ever going to be a killer app this would be it.

Re:Give us gtalk on linux already!

[Constantine XVI]

Gtalk does most logging server side, and the majority of xmpp clients have client-side logging

I hope so

[invisik]

Linux is still a second-class citizen in the eyes of many vendors that claim to support it. Google apps, Novell apps, drivers, HP/Lenovo programs, etc. It's about time things start to catch up.

Keep them coming and think "simultaneous releases" !!

-m

64 bit Google Earth

[phrostie]

a 64 bit version of Google Earth would be awesome!

Re:64 bit Google Earth

[Nimey]

How is the 32-bit client limiting you?

Re:Shitty Linux font rendering

[Chemicalscum]

No this is not

Shitty Linux font rendering the font rendering is excellent if you look at the original pdf of the presentation:

https://www.linux-foundation.org/images/6/6e/Dam4_ google.pdf

The shitty looking fonts on the web page are due to poor scaling of the original images that are linked from Phoronix:

http://www.phoronix.net/image.php?id=751&image=goo gle_new_preview

where the fonts still look good.

I love linux google desktop.

[Glytch]

I'm as much of an open-source advocate as anyone, but considering the four day hair-pulling nightmare that was my experience with beagle, google desktop for linux was a five minute cakewalk.

I was indifferent to mono before that little adventure. Now, it's my firm belief that mono and all that's associated with it can burn in hell.

Re:Crumbs from the table aren't appealling

[abigor]

An interface is slow when it commonly requires chains of arcane data structures as parameters, and many Win32 API calls do just that. An interface is buggy when there are 17 ways to do something, each producing a slightly different result. Windows API developed both of these traits over the years, and I only pity Microsoft for that, not blame them. But here they are, with a junk Win32 API and with a newer .NET layer built on top of that. I'm aware of the shortcomings of the Win32 api, as I used to code with it extensively in the '90s when I actually programmed for the Windows platform, but I don't really understand your point. Passing in pointers to parameters, no matter how "arcane", isn't slow, nor is dereferencing them to get the values you need. Pretty much anything passed by value are just integers, like window handles and stuff. Or maybe you mean "slow" as in time-consuming to code, in which case I suppose I agree. As for the second complaint, do you have an example of this 17 different ways to do something, all with slightly different results? That would be cool to see.

Re:Crumbs from the table aren't appealling

[tftp]

I was specifically mentioning pointers to large, complex data structures that often contain pointers to other, even more complex data structures. You can find those everywhere, for example look for LPSECURITY_ATTRIBUTES and follow the pointers and the methods that manipulate them. It's a lot of work to code it all correctly, and it's a lot of time to run it. If you code WDM drivers then such structures are everywhere, even to convert one ASCII string into one UNICODE string. You can see some code here.

With regard to 17 ways to do something, it's easy. Look at ReadFile vs. ReadFileEx, OpenFile vs. CreateFile vs. CreateFileTransacted - they are all generally doing the same thing. This was caused by freezing the API at various points in time, and when it was discovered that this and that function can't be implemented in existing API then a new method was concocted, with just the parameters for that new function, and so on.

But there are even more fundamental differences, when the whole API gets deprecated. For example, the Waveform API - you still can use it, but it's not nice and does not always offer you the best results. DirectX / DirectSound is more appropriate these days, though XAudio2 is also interesting, though you'd better know about X3DAudio if you are making games, though DirectSound3D could replace it for you. Fortunately, on Vista there is WASAPI in between the stack and the hardware, which only adds fun to the scope of your testing :-)

Indeed.

[dkegel]

Yes, the work done on IExplore for Picasa benefitted all apps that use embedded browsers. Wine's quality is far higher now than it was back when Corel tried it with Word Perfect; it's reasonable to expect a Wine app to run smoothly and without crashes these days -- if, that is, the vendor is willing to do a little QA and get a few Wine bugs fixed, like Google was. More companies should use Wine to port their apps to Linux, at least to get a toe in the water. If sales take off, they can dive in and do the native port.

Sketchup!

[vdammer]

I would love to see Sketchup ported over. It sure don't run on Wine, least as far as I have tried. My fingers are crossed.

Wine versions do NOT conflict.

[SanityInAnarchy]

Otherwise, they pack their own version of Wine, and it can conflict with a version of Wine a user already has installed.

Only if they have done a really stupid job of it.

I currently have at least three versions of Wine installed: Cedega, the latest Wine from WineHQ, and an older Wine for an older app that doesn't work with the newer ones.

All you need to do is set some environment variables: Where to look for the other Wine executables, and where to look for the Wine home directory (~/.wine). Not easy for an end-user to do, but it really makes it easy to ship software with a known-working version of Wine bundled.

In fact, Cedega itself has a really slick GUI for this, although I still avoid it when I can (WineHQ is so much better now at actually running the apps). It basically saves old versions of the Cedega engine (basically a proprietary Wine), and makes that a configurable option for each program -- which version of Cedega to use, right next to which version of Windows to emulate.

This same GUI also makes it possible, even easy, to set up multiple .wine directories (fake Windows installations). It calls them "game folders" or somesuch. The idea is, some Windows apps don't like being installed in the same place, and it also makes it much easier to debug things, since you can basically start with a clean Windows install for every game -- so that if there's a bug, you know it's that app and that version of Cedega, and not some other issue.

I've discovered that Wine 0.9.40, but no later, will run this old DirectX game better than Cedega ever has, so I've been trying to duplicate the features of that interface, but on the commandline...

Anyway.

Got a bit carried away there, but the point is: There's absolutely NO way Wine versions can conflict, unless you neglect to set one of two environment variables, documented right there in the Wine manpage. And libwine is a different story entirely, anyway, although I seem to remember that Picasa bundles Wine, rather than linking against libwine.