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?

[SCHecklerX]

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:Native?

[QuantumG]

No, it's not.

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

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?

[Anonymous Coward]

Google's done it with Google Earth. Not to kill your point, but isn't the linux version of Google Earth wine-based as well?

Re:Native?

[Anonymous Coward]

No, it uses Qt.

Re:Native?

[Anonymous Coward]

It's not google's job to fill in the gaps. The distro will take care of that. Always has for the thousands of applications already out there for every linux distro.

The beauty of the dynamic linker is that you can have multiple library versions co-exist quite peacefully together. If OpenGL games can run on multiple linux base distros, why can't (of all things) Picassa? Or [insert gApp here]? Worst case, google can link to RPM(s), DEB(s), or whatever they already pre-packaged themself. Binary globs? Do I really need to illustrate the process? Shoot, closed source binaries? I think google can handle it. I think your real argument lies with BSD, not linux.

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?

[HermMunster]

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 programs operate poorly under Linux, especially Google earth. Picassa is pretty sad too. I'm not saying they don't work. They do. But it is like having DOS programs run on OSX. You just wouldn't want it.

Re:Native?

[mad.frog]

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

Re:Native?

[Anonymous Coward]

Both Picassa and Google Earth are wine implementations done by Google.

Nope, only Picassa is.

Google Earth is a native linux app written using Qt.

Re:Native?

[clang_jangle]

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.

Re:Native?

[cheater512]

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.

Re:Native?

[clydemaxwell]

I can bundle wine myself. IF they're going to say 'here's a linux release', it should BE a linux release. So my answer is, conditionally, yes. They should be writing picasa from scratch. Helping the wine project is a secondary point...I am certain the wine developers would be fine if everyone wrote linux clients/apps and bypassed them, even eliminated them. That's sort've the GOAL.

Re:Native?

[vtcodger]

***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 do things. I care about how it is implemented only if it affects my use of the application. In this particular case, I kind of wish Google had used wine with the Linux version of Google Earth. If they had, it might work.

Re:Native?

[somersault]

Wait, isn't that what Microsoft does? How is that doing it 'right'? Or was that sarcasm.

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.

Re:Native?

[CarpetShark]

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.

Re:Native?

[jetxee]

Unicode support? The major problem with the current Picasa for Linux is that it does not support Unicode. I cannot enter cyrillic or japanese characters in it (I can if I run Picasa for Windows under Wine but it is _slow_). I cannot read even existing comments in cyrillic (they appear as UTF8-as-Latin1 in Picasa for Linux).

Another major issue is missing support for picasaweb. Thankfully, there is upload2picasa.py.

Re:Native?

[TheRaven64]

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

Re:Native?

[TheRaven64]

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.

Re:Native?

[GPL Apostate]

You reinforced my point. Google releases the source tarball. The 'distro' fills in the gaps.

As soon as people start allowing major packages to be distributed binary-only the Open Source process screeches to a halt and we're all running 'dozeII.

Re:Native?

[mikcorsi]

Yea i hope they just remake the3m from scratch so it was really made for Linux and not just being emulated for the system

Re:Native?

[Warbothong]

Not really. WINE itself can be used to run Windows-based programs, yes, but programs can also be built from source using libwine for the Windows-specific bits. That means programs are being built specifically to run on WINE, using it simply as a way of rewriting large parts of programs. That's what Google is using it for, their applications for Linux are built using libwine, they were not built using Windows functions and then dumped on top of WINE like most desktop WINE users do. Plus, to do this Google has improved WINE for all of us, which is nice (well, except for non-x86 people of course, they're still shafted like always).

Re:Native?

[Anonymous Coward]

No. I think you reinforce the obvious. You are an evangelist, not an end user.

Re:Native?

[lordtoran]

No, it uses Qt. Then why are the widgets and menus so ugly on the Linux version? They look more like Tk.

Re:Native?

[lordtoran]

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. I smell FUD. As long as the libraries it depends on are installed, the blob will happily run on any OS based on the Linux kernel.

Re:Native?

[mad.frog]

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.

Re:Native?

[cortana]

Because it uses QT! :)

More seriously, I expect it is because it ships its own copy of QT, which uses one of the default QT themes---'Windows' from the look of it---rather than whatever theme you have told your distro's copy of QT to use.

Re:Native?

[cheater512]

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.

Re:Native?

[Breakfast Pants]

I've made it a point that anytime this saying is applicable, it should be liberally applied: quit being such a baby.

Re:Native?

[JThundley]

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

"Some projects will be open source"

[tlevine]

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

Pinky and Google.

[Anonymous Coward]

"The Google presenters claimed some 'significant accomplishments' and other new Google desktop applications coming out this year for the Linux platform.""

So were's the "world domination" app?

Crumbs from the table aren't appealling

[Rix]

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:Crumbs from the table aren't appealling

[abigor]

How can an interface be buggy and slow?

Re:Crumbs from the table aren't appealling

[Annymouse Cowherd]

Well, Google Earth isnt buggy and slow on Windows, so a perfectly cloned implementation of the win32 API cant make it worse.

Re:Crumbs from the table aren't appealling

[tftp]

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

[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

[macshit]

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.

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

Re:Crumbs from the table aren't appealling

[Anonymous Coward]

It doesn't sound like you know what you are talking about.

Re:Crumbs from the table aren't appealling

[smilindog2000]

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.

Re:Crumbs from the table aren't appealling

[somersault]

Have you read any of the parent comments at all?

Re:Crumbs from the table aren't appealling

[Frankie70]

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?

Re:Crumbs from the table aren't appealling

[cyclop]

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.

Re:Crumbs from the table aren't appealling

[Arslan ibn Da'ud]

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.

Re:Crumbs from the table aren't appealling

[angrykeyboarder]

And it's butt ugly.

Re:Crumbs from the table aren't appealling

[abigor]

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.

Re:Crumbs from the table aren't appealling

[IllForgetMyNickSoonA]

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

Re:Crumbs from the table aren't appealling

[Frankie70]

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.

Re:Crumbs from the table aren't appealling

[IllForgetMyNickSoonA]

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

Re:Crumbs from the table aren't appealling

[cortana]

Those are all library functions wrapping the same underlying system call (execve).

Re:Crumbs from the table aren't appealling

[jZnat]

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.

Funny enough, I just installed googleearth...

[MMC Monster]

Any idea if a .deb file for googleearth 4.2 will be available? I'm interested in playing with google sky. :-)

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.

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

[Anonymous Coward]

Just get googleearth-package and it will do the rest for you

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

[Anonymous Coward]

just download their .bin installer. it will just install in your home dir under ~/googlearth or something. if you want to uninstall it just delete that.

maybe google will host ubuntu/debian repos for their apps so that then you can get the latest the proper way indeed.

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

[speaker of the truth]

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:Funny enough, I just installed googleearth...

[ForumTroll]

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.

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

[Anonymous Coward]

OK, how about open gui install tool, probably labelled something like 'install software', select desired program, click OK. That simple enough for you? If not, maybe you should stick to kindergarten bricks.

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

[Anonymous Coward]

To be fair, to do the equivalent on windows, step one would be 'program a package manager'. I think that would take longer.

blinded by ads

[Loconut1389]

I looked, saw 99% ads and 1% article and left the page- someone actually feel like wading through that?

Re:blinded by ads

[Rakshasa Taisab]

What ads? You must have been clicking on the wrong interwebs or something.

Re:blinded by ads

[Loconut1389]

you mean the big one floating over the page and a million adwords sized ads?

Re:blinded by ads

[tlevine]

I didn't, but I didn't have to. (AdBlock Plus)

Re:blinded by ads

[Anonymous Coward]

What are you talking about? lrn2interbutt, man. The page is pretty easy on the eyes from where I'm sitting.

Firefox + Adblock Plus + Adblock Filterset.g Updater

http://img241.imageshack.us/img241/7836/screenshot wh7.png

Re:blinded by ads

[saskboy]

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

Re:blinded by ads

[krunchyfrog]

What ads?

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

[greenguy]

Dude. Wake me when there's Google Inkscape.

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

[ScislaC]

Any chance you want to elaborate on that?

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

[greenguy]

Er... I'd like to be able to create and edit SVG files within a web browser, in a WYSIWYG format.

Is that helpful?

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

[neoform]

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

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

[mav[LAG]]

Replace "google" with "Microsoft" in the above post for surprising insight.

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

[Anonymous Coward]

Or "apple", or "hp"..

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

[LauraW]

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 Ubuntu boxes piled around my desk at the moment, plus one Windows (yuck) laptop because I'm too lazy to try to make Linux play nice on a laptop.

I'm not involved in much open source work (aside from using it) but as far as I know Google contributes back to a fair number of OSS projects and organizations including GNU/FSF and Linux, plus Webwork/Struts and various other Java projects. I don't know too many details, though. There are also a number of smaller OSS projects started by Googlers; the one I'm most familiar with is the Guice dependency injection framework for Java because I've been using it a lot in my work lately. You can browse around on code.google.com to find others.

Disclaimer: I (obviously) work for Google in engineering, but not on any open-source projects. Nothing I've said above is new or secret; you can find articles about this kind of thing with a bit of searching. There was an interview with Wayne Rosing in ACM Queue a couple of years ago that talked about some of it, and a more recent one with Douglas Merrill in another magazine or newspaper.

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

[rtb61]

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/ 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. Fixed the customize google tool I just use to block google analytics now but I unloaded google search from the firefox search bar as well as deleting every other bit of google software.

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]

Welcome the the new and improved intarwebs!

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:TFA is spam??

[Twisted64]

I clicked on the link to TFA.

You must be new here.

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!

[iabervon]

There's a Google Talk program? What they ought to do is contribute support for Google's XMPP extensions to Pidgin.

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

Re:Give us gtalk on linux already!

[scvalex]

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

I wouldn't call it killer. There are already 2 clients for linux that do everything (over most protocols) but voicemail, and voicemail isn't really that important or fun.

Re:Give us gtalk on linux already!

[LingNoi]

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.

Re:Give us gtalk on linux already!

[MadJo]

or at the very least help the Pidgin people get support for those features.

Re:Give us gtalk on linux already!

[consonant]

I'd just be happy if they made the Gtalk client more usable in general. A bajillion months out in user-land and still no friggin' way to maximize a window? Still cannot organize contacts? Still no way to send a message to a bunch of users? You have GOT to be kidding me! What kind of IM tool is this anyway, that's actually worse than its web-based counterpart? (The Google Talk Gadget)

Re:Give us gtalk on linux already!

[Anonymous Coward]

I think I'm starting to catch on to your situation now. Boris, who is pretending to be Sasha (your little internet sweetheart) keeps giving you the "Oh I can't actually speak with you live. Damn this Gtalk and it's lacking Linux support." If only Google would port Gtalk properly Boris would have no choice but to out himself. But that would be the end of your relationship (I'm assuming). You sure you want Gtalk ported?

Re:Give us gtalk on linux already!

[Walter Carver]

Version 1.4.2 of jabberd supports this. Pidgin 2.1.1 (whish is the latest at the time of writing this) doesn't support this feature yet.

tag blogspam

[Anonymous Coward]

this is happening too much lately. any link that is >50% ads should not be allowed onto the front page!

Re:tag blogspam

[Anonymous Coward]

And how would that happen? It's not like the "editors" actually look before posting.

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

What about other Unices?

[Vardamir]

While this is good news, better news would be Google developing apps for Unix in general, and not Linux specifically.

Re:What about other Unices?

[GPL Apostate]

If Google would release a source tarball, the community would do the porting work for them.

Re:What about other Unices?

[G Morgan]

./configure
make
make install

Port done.

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:64 bit Google Earth

[pak9rabid]

He's probably pissed that it won't address the 16 gigs of memory in his LED-happy ricer box

Re:64 bit Google Earth

[phrostie]

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.

Re:64 bit Google Earth

[Nimey]

*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).

Re:64 bit Google Earth

[Dr.Dubious DDQ]

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 painfully slow software rendering (though at least it runs).

I'm under the impression that this is actually a problem with ATI's drivers, though the fact that Google Earth is the ONLY application that seems to have trouble with it right now. Given that Google Earth is actually the only thing I especially want to run with 3D hardware acceleration, this has been extraordinarily frustrating for me for well over a year now.

I suspect either ATI, Google, Or x.org's developers could solve the problem - Google by bypassing whatever specific feature is causing the lockup, ATI by making the driver respond correctly, or x.org by figuring out how to initialize the Radeon XPRESS 200M correctly (there's evidently something strange about the chipset and ATI won't reveal how to properly initialize it) so I can use the open-source drivers. But so far, the former two just don't seem to care, and the latter is still trying to get it worked out.

I wonder how the java Worldwind project is running on Linux these days?...

Re:64 bit Google Earth

[phrostie]

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

Re:64 bit Google Earth

[CopaceticOpus]

Imagine seeing Google Earth in 64 bits! It'd be like being there!

Re:64 bit Google Earth

[Dr.Dubious DDQ]

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 that it's supposedly a new codebase. I'm hoping it'll contain a fix for this obnoxious and seemingly perpetual problem, too, but I have no idea if it will.

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.

Will it be CORN powered?

[Anonymous Coward]

If GOOGLE builds it, they will come...

Signed,

The Cowardly Lion

sure seems like

[Anonymous Coward]

not too many people care about this.

Re:sure seems like

[jshackney]

I was thinking the same thing. I've happily removed Google Earth and Picasa. I just don't find either application particularly interesting.

Re:sure seems like

[larry bagina]

I had high hopes when I started using picassa... I was hoping for something like iTunes for photos, where you could create virtual photo albums based on criteria (such as resolution, tags, date, etc) and do random slide shows (this is for porn, of course). Picassa is ass.

Re:sure seems like

[Anonymous Coward]

Digikam may be what you're looking for.

Googel?

[Anonymous Coward]

Am I the only person who doesn't get the "googel" tag?

Re:Googel?

[BluBrick]

Nope.

OTOH, would it really bother you if you were?

Re:Googel?

[marzipanic]

I like Gmail but am not a lover of Google Earth and Picassa, I don't see the big deal about them but whatever floats ones boat I guess. I am new to Linux and bowled over by it (you know what us new converts are like).

Will it be PORN powered? My mother once googled "French Dictionary" as she needed one... she didn't quite find what she was looking for but she said it was a real eye opener!

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:I love linux google desktop.

[xophos]

I for my part would much rather do without any desktop search than give a corporate entity access to all my data without even putting up a fight.

Re:I love linux google desktop.

[Glytch]

By default, google linux desktop doesn't store any data on their servers. It's all stored in ~/.google/desktop. One has to specifically checkmark "Enable Advanced Features" (basically Q&A application reporting) for google to get any data from one's machine. It's also easy to tell it to exclude any directory you want. On the first preferences page, it's the 3rd item of 4 in big bold text. It's not hidden away.

Of course, one could claim that since it's a closed-source app, it could be doing anything. But how is that any different from having to installing a binary .deb or .rpm for Mono and Beagle, because building from source results in constant "Could not load file or assembly glib-sharp" and "Got a SIGSEGV while executing native code" errors? (And yes, gtk-sharp was built and installed properly, or so it claimed when running make install.)

If the signed source doesn't work and I have to use a binary from some strange unknown repository, it's effectively closed-source to me.

Re:I love linux google desktop.

[xophos]

I don't use closed source Applications in my linux installation.

But even if i would, google desktop would not be one of them:

When some closed source app starts to read files that it's not supposed to read, word of that will soon spread. (as happened with skype)

But when an application is supposed to read all my files to index them, there is just no way i trust a closed source app with that.

Especially not an app from a company that doesn't care the least about other peoples privacy.

Misread

[r_jensen11]

Damn, the mis-read was soo much better:

Will it be PORN powered?

Whats brewing?

[ikarys]

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)

Re:Google(c) is a problem!!!

[eldepeche]

AC non sequitur of the day!

They meant Google Desktop

[dkegel]

The guys who put on those slides were talking
about Google Desktop, but couldn't mention it by
name yet.

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.

Re:Sketchup!

[JohnBailey]

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. Thats something I would be happy to see too. It almost does. Painfully close every time I try it. Keep hoping :-)

Re:Sketchup!

[adamofgreyskull]

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!!

GTALK.gtalk.

[MrCopilot]

Google Talk, Gtalk , gtalk . gtalk gtalkgtalkgtalk....Goggletalk

Sounds like IA32 to me

[Per Abrahamsen]

Yet, there are processors out there implementing the IA32 interface which are definitely not slow.

Re:Sounds like IA32 to me

[Bert64]

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

Brad Fullenbach here

[Anonymous Coward]

And Hi.

Do you want to work for google or do you know anybody who might?

Thank you, hope to hear from you real soon,

Brad Fullenbach

The client needs MUC Groups

[ishmalius]

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.

Choice from the Unix table aren't appealling

[Anonymous Coward]

OK, so choice is a problem for you. Try the Linus/Unix platform. I hear they don't have any choice. Should make programming a breeze.

Re:Choice from the Unix table aren't appealling

[lordtoran]

Redundance != choice!

sorry, haven't had my coffee yet....

[Anonymous Coward]

The goal of the Google Linux Client Team is to develop Linux desktop applications

*stunned*

Do Not Want

[Anonymous Coward]

Do Not Want Do Not Want Do Not Want

GooBuntu Anyone??

[Anonymous Coward]

GooBuntu Anyone?? /Ducks

Trinkets?

[Gothmolly]

How about an Exchange killer? How about making gmailfs "real"? How about ANYTHING other than Google Earth and Picassa? You know, for people who use their computers, for something other than MySpace.

Here is what irritates the hell out of me...

[PenguinBoyDave]

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?

Sorry to disappoint you

[MimsyBoro]

Although it isn't perfect you must give a lot of respect to the Windows API.

And just to show how much you are out of sync one example:

  * OpenFile -- depracted (backwards compatibility with Win16)
  * CreateFile -- the only way to open a file
  * CreateFileTransacted -- new in Vista to support Transacted File Systems (and not to break backwards compatibility).

The waveform API is another example. It's mainly maintained for backwards compatability but is still very usefull for most programs that just want to simply play a sound/capture sound from a microphone. If you need fancier stuff use the DirectSound API. If you are writing games (and you want them to also work on Xboxes) you should use specific APIs for that.

Come on, I feel like strangling MS developers daily but I also give credit where it's due.

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.

What distro?

[SanityInAnarchy]

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 through them is lightning-fast. That's really what I want out of a desktop search, by the way -- let it provide an optimized version of grep.

Kopete.

[SanityInAnarchy]

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.

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, 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 protocol support, compared to Pidgin -- it seems to disconnect every few hours, which isn't a huge deal, because it reconnects automatically, and the conversation window is still open. And it occasionally crashes for no apparent reason -- I'm on amd64, but that shouldn't matter.

But, other than that, it's been great. Even the crash isn't a big deal, because it takes something like three seconds to open again, and it connects to KDE Wallet for passwords, so I don't have to enter a password the second time.

Re:Shitty Linux font rendering

[Anonymous Coward]

And you sir are just a fucking idiot.

Re:Stupids Linuxers/Linuxians!!!

[Anonymous Coward]

I'm tellin' on you!

Mama, Mama!!!!
AC called me STUPIDS!!!111!!!!oneoneone

Yeah

[Anonymous Coward]

2,147,483,648 square metres ought to be enough for anybody.