Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Google Software Businesses The Internet Linux

New Google Apps For Linux Coming 159

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."
This discussion has been archived. No new comments can be posted.

New Google Apps For Linux Coming

Comments Filter:
  • Native? (Score:5, Interesting)

    by colourmyeyes ( 1028804 ) on Sunday September 02, 2007 @07:38PM (#20446925)
    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.
      • Wine is buggy and slow. That isn't the wine developer's fault, they're implementing a buggy and slow interface.

        If they're going to do it at all, they should do it right. Slapping shit on a shingle just makes the whole thing look bad.
        • Re: (Score:1, Offtopic)

          by abigor ( 540274 )
          How can an interface be buggy and slow?
          • 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.
            • 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.

              • 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 :-)


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


                  Q) How do I create a new Process?
                  A) First call fork(), then call execl, execle, execlp, execv, execve, execvp, or exect

                  How much simpler can it be?
                  • Now, it's been a REAL LONG time since I programmed something under Win32, but I think to remember - please correct me if I am wrong - that one actually needs a *bleep*ing window handle(!!!) to create a new process (or was it a thread?) in Win32.

                    I'll take the execl/execle/execlp/execve/execvp/exect zoo over that any time! :-)

                    • please correct me if I am wrong - that one actually needs a *bleep*ing window handle(!!!) to create a new process (or was it a thread?) in Win32.

                      Ok. I'll correct you. You are wrong. You don't need a bleeping window handle
                      to create a process.

                      Next.
                    • I stand corrected, thanks.

                      If I find some time, I'll try to find what I was talking about (there *was* a case where I was shocked to see Win32 to expect a bleeping window handle, I just have to go digg a bit).
                  • by cortana ( 588495 )
                    Those are all library functions wrapping the same underlying system call (execve).
                • 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 :-)

                  But there are even more fundamental differences, when the whole API gets deprecated. For example, the OSS - you still can use it, but it's not nice and does not always offer you the best results. ALSA is more appropriate these days, though ARTS is also interesting, though JACK could replace it for you. Fortunately, on KDE4 there is phono in between the stack and the hardware, which only adds fun to the scope of your testing :-)

                  I guess Linux isn't much different regarding sound.

                  • by jZnat ( 793348 ) *
                    Good point. Sound APIs seem to be a mess across the board. Personally, I would just stick with something like SDL so I wouldn't need to worry about all these extraneous APIs.
                • by abigor ( 540274 )
                  Haha, I suppose you are right about the 17 different ways. And don't forget about CreateThread, _beginthread, and _beginthreadex! I remember these giving me fits.

                  But as another poster pointed out, exec() isn't any better ;) No interface is without cruft, I suppose, though the Win32 api is cruftier than most.
            • Yet, there are processors out there implementing the IA32 interface which are definitely not slow.
              • by Bert64 ( 520050 )
                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
          • by macshit ( 157376 )
            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.
              • by cyclop ( 780354 )

                I am a KDE guy, but I must admit that Konqueror also sucks in the same cases (don't know with KDE 4)

                However, as a spare-time programmer (brrr!!) I would really like to know what can I read to avoid at least the most trivial of such pitfalls -for GUIs and for anything else.

        • Well, Google Earth isnt buggy and slow on Windows, so a perfectly cloned implementation of the win32 API cant make it worse.
      • Re:Native? (Score:5, Insightful)

        by colourmyeyes ( 1028804 ) on Sunday September 02, 2007 @07:56PM (#20447055)
        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.
        • by QuantumG ( 50515 )
          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.
          • The best solution would be to keep most of the code as is, using winelib, and rewrite the GUI with a native toolkit (and, more importantly, native behaviour).
        • Wine is for running applications that CANNOT be ported, e.g. commercial software like MS Office.


          No, it's for making things work when the companies in question don't care.
        • 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

        • I've made it a point that anytime this saying is applicable, it should be liberally applied: quit being such a baby.
        • A native Linux version of Picasa doesn't seem preposterous to me. Google's done it with Google Earth.
          Actually, Google Earth is built with wine the same way Picasa is. link [gearthblog.com]
      • 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
      • should they be writing picasa fom scratch?

        Yes, of course they should.
        I mean really, why would any informed linux user want to take on all the security concerns of the windows APIs? Shoot, I regret that I require OO.org for all those stupid wurd and pp docs everyone uses. I'm *certainly* not running WINE or any other reimplementation. I want my secure non MS boxen to stay that way.
    • 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.
    • Re: (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 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."
        • Wait, isn't that what Microsoft does? How is that doing it 'right'? Or was that sarcasm.
          • Wait, isn't that what Microsoft does?

            Yep.

            How is that doing it 'right'?

            Because it allows people to distribute apps without source code if they so choose, with assurance that the ABI is still supported.

            Because it allows people to distribute apps WITH source code, with assurance that they will still compile and function correctly years later.

            Granted, Microsoft has done a crappy job of "API creep" (OpenFile, CreateFile, CreateFileEx... stop the madness!), but an amazing job of keeping old apps working.
    • 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.
        • Winelib is basically just another X11 toolkit, which happens to be close to identical to the win32 API. This is not what Google used, they simply shipped the Windows binary with a build of WINE wrapped around it.
          • The winelib page disagrees with you:

            Compiling apps under Winelib should theoretically involve only makefile changes. In practice, you will encounter header problems, and the likes

            Since Google has the source to their windows software, there is no reason at all why they wouldnt just recompile it with winelib for Linux.
      • ***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.
      • Wow, that sounds so easy for a non-Linux user. I don't know why more people don't jump over to the OS.
        • 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.
  • I looked, saw 99% ads and 1% article and left the page- someone actually feel like wading through that?
    • What ads? You must have been clicking on the wrong interwebs or something.
    • by tlevine ( 863948 )
      I didn't, but I didn't have to. (AdBlock Plus)
    • by saskboy ( 600063 )
      " 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.
  • 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.
      • Basically, first I searched for a KDE variant of Beagle, since I run Kubuntu. I found Kerry.

        Then, installed one app from the package manager, and done. It grabbed Mono and set everything else up fine, I was already on XFS, so extended attributes were supported, and it just worked (well, once it had indexed everything).

        However, recently, I was a complete moron and lost ALL of my data, so this time around, no desktop search at all. No point -- I have maybe ten or twenty note files, all text, and grepping thro
    • Dude. Wake me when there's Google Inkscape.
    • by neoform ( 551705 )
      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
        • by mav[LAG] ( 31387 )
          Replace "google" with "Microsoft" in the above post for surprising insight.
        • by LauraW ( 662560 )

          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.

          You win the prize. Most engineers at Google use Ubuntu, though it's a somewhat customized Ubuntu that integrates features like good LDAP support, kerberized NFS, etc. that are important in a company this size. (I'm posting this from a workstation running Kubuntu right now, bored while waiting for a build to finish.) Our excellent internal IT folks have made it very easy to set up a new Linux box and get it on the internal network with all of this stuff configured correctly. I've actually got three Ub

          • by rtb61 ( 674572 )
            It is nice that the google engineering people do good work, although I am particularly pissed off with the hack for http://www.customizegoogle.com/ [customizegoogle.com] so that the results that people wanted filtered out still suck up space but are greyed out, really arrogant, fuck the customer stuff.

            Perhaps if some of the more morally inclined google staff would attempt to get their honesty and integrity spread through the rest of the organisation especially the marketing team and management we end user might be better off.

  • 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.
    • I clicked on the link to TFA.
      You must be new here.
  • 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.
    • by iabervon ( 1971 )
      There's a Google Talk program? What they ought to do is contribute support for Google's XMPP extensions to Pidgin.
    • Re: (Score:3, Informative)

      Gtalk does most logging server side, and the majority of xmpp clients have client-side logging
    • by MadJo ( 674225 )
      or at the very least help the Pidgin people get support for those features.
    • The one thing that is left out of the client, Multi-User Chat Groups, should really be added to the client. I realize that Google probably doesn't want the legal hassles of managing chat "rooms." But they don't need to put them on their server, just give the client the ability to use MUC on -other- conference servers.
    • I haven't tried it, because I no longer have a functioning headset for my computer. But a quick Google search, and: here it is [kde.org].

      It's not in a usable state yet, apparently, at least not with the Gtalk people -- although there are plenty of other ways to voice chat on Linux. My personal favorite, if I ever bother to setup a server, is mumble [sourceforge.net], which really should be killing Ventrilo (but somehow isn't).

      I've generally found Kopete to have all the features I want, and then some. It also has some issues with its p
  • I hope so (Score:3, Interesting)

    by invisik ( 227250 ) on Sunday September 02, 2007 @08:12PM (#20447149)
    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
  • While this is good news, better news would be Google developing apps for Unix in general, and not Linux specifically.
  • 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!
    • Re: (Score:3, Interesting)

      by Nimey ( 114278 )
      How is the 32-bit client limiting you?
      • He's probably pissed that it won't address the 16 gigs of memory in his LED-happy ricer box
      • i can get newer versions to install, but it won't run past the splash.

        i've had the older verions running, but that's been a while.

        if there is a trick, i'm all ears and eyes.
        • by Nimey ( 114278 )
          *shrug* I just downloaded the latest version (4.2, with the flight sim) and it seems to work just fine.

          FWIW: GeForce 7900GS (proprietary driver), 2GB of RAM, Core 2 Duo E6300, Asus P5B-VM motherboard, Ubuntu 7.10 (64-bit).
        • You're stuck on an ATI video chipset, aren't you?

          This is an OLD problem that nobody seems to care about addressing, if it's the same problem I'm having. My laptop here is stuck with the "Radeon XPRESS 200M" video chipset. ATI's special proprietary drivers seem to work okay...except for Google Earth which sticks at the splash screen with near 100% CPU utilization. The only "fix" I've ever found involves copying an old version of libGL.so into the Google Earth install directory, which forces it to run in

          • you described it perfectly.

            and yes it used to work in software mode, abet painfully slow. it stopped working when i got my ATI drivers working

            did you use the mesa libgl.so?

            btw, thanks for the tip
            • did you use the mesa libgl.so?

              As I recall, I had originally extracted the older libgl.so from an older version of the ATI proprietary drivers. The previous version of the proprietary driver (8.39.4) seemed to work without it, albeit still in painful software rendering mode, so I made the mistake of deleting the file. Now I'm back to the "doesn't work at all" situation again with 8.40.4.

              Phoronix was just raving about how wonderful the about-to-be-released next version (8.41.something) is going to be, and

    • Imagine seeing Google Earth in 64 bits! It'd be like being there!
  • by ikarys ( 865465 )
    Perhaps some glinux will be coming out. Simple to use/setup, powerful, and wont have the hardware problems and glitchyness of standard linux distros. (I've used Ubuntu for 6 months as a developer.. and its not quite there yet)
  • The guys who put on those slides were talking
    about Google Desktop, but couldn't mention it by
    name yet.
  • 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.
    • I was looking for this just last night. I can't wait for this to get ported, I want to be able to see my house from the window of my new aeroplane!!
  • Google Talk, Gtalk , gtalk . gtalk gtalkgtalkgtalk....Goggletalk
  • I go to this blog with Firefox, and it looks like crap. Then I notice that it says it is best viewed in Opera. A little ironic isn't it?

"The following is not for the weak of heart or Fundamentalists." -- Dave Barry

Working...