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."
What the heck? I clicked on the link to TFA. It sent me to a page at techrythm.com, where there is an extremely short article, giving hardly any more information than the slashdot summary. In it are a lot of links double-underlined in green. When I move my mouse over the links, I get an ad floating around. When I click on a link, I go to some lame spam page that doesn't seem to have anything to do with what the link claims it is.
Find free books.
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.
"A Lisp programmer knows the value of everything, but the cost of nothing." - Alan Perlis
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.
Gtalk does most logging server side, and the majority of xmpp clients have client-side logging
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
No, it uses Qt.
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.
Do you even lift?
These aren't the 'roids you're looking for.
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.
Don't thank God, thank a doctor!