Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Google Apps For Linux Coming

Posted by kdawson on from the bated-breath dept.

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."

14 of 159 comments (clear)

  1. Native? by colourmyeyes · · Score: 5, Interesting

    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.

    --
    My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
    1. Re:Native? by yincrash · · Score: 5, Interesting

      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.

    2. Re:Native? by colourmyeyes · · Score: 5, Insightful

      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.

      --
      My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
    3. Re:Native? by GPL+Apostate · · Score: 3, Insightful

      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.

      --
      Microsoft says legacy (serial/parallel) ports are bad. They don't obfuscate the hardware enough.
    4. Re:Native? by kripkenstein · · Score: 3, Insightful

      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.
  2. "What could this be? Google Desktop for Linux?" by footissimo · · Score: 3, Funny

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

  3. TFA is spam?? by bcrowell · · Score: 4, Informative

    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.

    --
    Find free books.
    1. Re:TFA is spam?? by Anonymous Coward · · Score: 3, Funny

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

    2. Re:TFA is spam?? by bcrowell · · Score: 5, Informative

      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.

      --
      Find free books.
  4. Give us gtalk on linux already! by LingNoi · · Score: 4, Interesting

    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.

  5. 64 bit Google Earth by phrostie · · Score: 3, Interesting

    a 64 bit version of Google Earth would be awesome!

  6. Re:Crumbs from the table aren't appealling by abigor · · Score: 3, Interesting

    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.

  7. Re:Crumbs from the table aren't appealling by tftp · · Score: 3, Interesting
    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 :-)

  8. Indeed. by dkegel · · Score: 3, Insightful

    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.