Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

New Google Apps For Linux Coming

Posted by kdawson on Sun Sep 02, 2007 07:32 PM
from the bated-breath dept.
Software Businesses Google The Internet Linux
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."
+ -
story

Related Stories

Submission: New Google Linux Apps Coming Soon !! by techoon (1150597)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

New Google Apps For Linux Coming 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Native? (Score:5, Interesting)

    by colourmyeyes (1028804) on Sunday September 02 2007, @07:38PM (#20446925) Homepage
    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? (Score:5, Interesting)

      by yincrash (854885) on Sunday September 02 2007, @07:42PM (#20446957)
      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? (Score:5, Insightful)

        by colourmyeyes (1028804) on Sunday September 02 2007, @07:56PM (#20447055) Homepage
        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.
        • No, it's not.

          WINE is also for aiding the porting process from Windows to Linux.

        • Re:Native? (Score:4, Insightful)

          by kripkenstein (913150) on Monday September 03 2007, @06:05AM (#20450321) Homepage

          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.

        • 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

            • Re: (Score:2, Informative)

              by larry bagina (561269)
              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.

      • Indeed. (Score:3, Insightful)

        by dkegel (904729)
        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

          • Re: (Score:2, Offtopic)

            by tftp (111690)
            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.

            • Re:Crumbs from the table aren't appealling (Score:4, Interesting)

              by abigor (540274) on Sunday September 02 2007, @09:07PM (#20447487)

              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 (Score:4, Interesting)

                by tftp (111690) on Sunday September 02 2007, @09:33PM (#20447639) Homepage
                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 [microsoft.com] 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 [microsoft.com] 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 :-)

            • Yet, there are processors out there implementing the IA32 interface which are definitely not slow.
              • But how much faster could they have been if the same effort had been made on a more sane interface?
                Modern IA32 compatibles have to jump through hoops to get good performance
          • How can an interface be buggy and slow?

            Er, well, interfaces can be horribly designed, full of unnecessary legacy crap and artifacts of machine dependencies that nobody in their right mind would have let leak into an interface (but did). Worse, such the painful details of such insanely awful interfaces are often barely documented, if at all.

            These attributes tend to to make code supporting such an interface buggy and slow.
            • It turns out that few GUI programmers are good with data structures, and slow GUIs plague many applications as a result. My favorite is list boxes when they contain thousands of elements. Every implementation I've seen chokes. Here's a specific one on Linux: The stupid Nautilus file browser. Try viewing a directory with > 10000 files sometime... good luck. Even viewing /usr/bin is stupidly slow. GUI programmers love introducing N^2 loops, and there are often N^3 loops.
    • Yeah, I was going to post with a "Don't bother" if it's going to be picassa-ish. What a piece of crap that is on linux.
    • 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 binar
      • If Google wants to do it right, they will settle on a single API -- or concoct their own -- and say "this is the so-called 'Linux' we will support. If you want our apps to run, your distro better supply it. If not, tough."
    • Both Picassa and Google Earth are wine implementations done by Google. This has always been an extremely bad idea. If you are going to commit to a platform you do it. You don't taunt the platform with the competitors executables. Not only that Google has taken so much from the Open Source community and given so little back. It is about time they take the time to redo these and ensure that they never again try to pull the wool over our eyes with these fake Linux programs.

      Not to mention those wine progra
      • I was under the impression that winelib was used to essentially convert the source code in to native code.
        Thats why it requires source and it spits out a nice native binary at the end.

        Instead of dynamically translating API calls, it does it at compile time.
      • ***Both Picassa and Google Earth are wine implementations done by Google. This has always been an extremely bad idea.***

        No and No.

        Picassa uses the Windows code base and the wine library and runs acceptably. Google Earth uses the Qt and GL libraries and runs acceptably on some machines. On others it crashes. On this particular machine, it not only crashes during initialization, it takes the X-windows session with it when it leaves.

        I don't know about you, but when I run an application, I want it to d

  • Why not all? (And why no hyphen either?)
  • Any idea if a .deb file for googleearth 4.2 will be available? I'm interested in playing with google sky. :-)

    • Re: (Score:3, Informative)

      by ForumTroll (900233)
      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.

        • Re: (Score:2, Flamebait)

          by ForumTroll (900233)
          Nobody said that you had to do it that way. That's only if you want it integrated with the package manager. You could just download the installation file from Google and install it that way if you so desire. Furthermore, I really don't care if it's easy for non-Linux users, or if people "jump over" to Linux. Use whatever operating system you want, I really couldn't care less.

  • "What could this be? Google Desktop for Linux?" (Score:3, Funny)

    by footissimo (869107) on Sunday September 02 2007, @07:53PM (#20447031)
    Ooo..I'm really looking forward to them porting that one [google.com]
    • 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.
    • Dude. Wake me when there's Google Inkscape.
        • Er... I'd like to be able to create and edit SVG files within a web browser, in a WYSIWYG format.

          Is that helpful?
    • Maybe I'm alone on this one, but doesn't it make a lot of sense that Google is actually making their own flavor of linux, which is why they're making linux versions of their apps? I mean hell, how many people really use linux on their desktops?

      Sure google might have denied that they're making their own OS.. but they're not under oath and can easily say "no we aren't" until it's been approved by upper management.

      Personally, this makes me believe (strongly) that they are working on a flavor of linux.

      • Re: (Score:3, Insightful)

        by rtb61 (674572)
        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 stabilit

  • TFA is spam?? (Score:5, Informative)

    by bcrowell (177657) on Sunday September 02 2007, @08:00PM (#20447081) Homepage
    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: (Score:3, Funny)

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

    • Re:TFA is spam?? (Score:5, Informative)

      by bcrowell (177657) on Sunday September 02 2007, @10:14PM (#20447887) Homepage
      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.

  • Give us gtalk on linux already! (Score:5, Interesting)

    by LingNoi (1066278) on Sunday September 02 2007, @08:07PM (#20447113)
    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.
    • There's a Google Talk program? What they ought to do is contribute support for Google's XMPP extensions to Pidgin.
    • Gtalk does most logging server side, and the majority of xmpp clients have client-side logging

      • There are already 2 clients for linux that do everything (over most protocols) but voicemail, and voicemail isn't really that important or fun.
        Both crash and suck, Tapioca for example just freezes for me.

        Voicemail isn't important to YOU. I have a girlfriend in a different country and the ability to leave her voicemail messages is important for ME. I hate the BS arguments about the importance of features.

  • I hope so (Score:3, Interesting)

    by invisik (227250) on Sunday September 02 2007, @08:12PM (#20447149) Homepage
    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 (Score:4, Interesting)

    by phrostie (121428) on Sunday September 02 2007, @08:17PM (#20447189)
    a 64 bit version of Google Earth would be awesome!

  • Sketchup! (Score:2, Interesting)

    by vdammer (796081)
    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.
  • Google Talk, Gtalk , gtalk . gtalk gtalkgtalkgtalk....Goggletalk
    • What ads? You must have been clicking on the wrong interwebs or something.
    • " About

      This is an example of a WordPress page, you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress."

      It's a SPLOG people! I Firehose tagged it as spam yesterday.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.