Slashdot Mirror
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."
As TFA says, Picasa for Linux wasn't native, just a Windows version repackaged with Wine. I hope the new stuff isn't like that.
My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
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. :-)
Help! I'm a slashdot refugee.
I looked, saw 99% ads and 1% article and left the page- someone actually feel like wading through that?
Ooo..I'm really looking forward to them porting that one
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.
Well, Google Earth isnt buggy and slow on Windows, so a perfectly cloned implementation of the win32 API cant make it worse.
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.
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
http://www.invisik.com
While this is good news, better news would be Google developing apps for Unix in general, and not Linux specifically.
a 64 bit version of Google Earth would be awesome!
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.
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 was thinking the same thing. I've happily removed Google Earth and Picasa. I just don't find either application particularly interesting.
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.
OTOH, would it really bother you if you were?
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
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.
We live, as we dream -- alone....
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)
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 :-)
AC non sequitur of the day!
The guys who put on those slides were talking
about Google Desktop, but couldn't mention it by
name yet.
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.
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 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.
Do you even lift?
These aren't the 'roids you're looking for.
Google Talk, Gtalk , gtalk . gtalk gtalkgtalkgtalk....Goggletalk
OSGGFG - Open Source Gamers Guide to Free Games
Yet, there are processors out there implementing the IA32 interface which are definitely not 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.
Beer is proof that God loves us, and wants us to be happy.
Have you read any of the parent comments at all?
which is totally what she said
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.
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?
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.
-- Patent no.123456: A way to personalize
I guess Linux isn't much different regarding sound.
Practice Kind Randomness and Beautiful Acts of Nonsense.
And it's butt ugly.
Scott
©20014 angrykeyboarder & Elmer Fudd. All Wights Wesewved
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.
I want to delete my account but Slashdot doesn't allow it.
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?
I'm not a troll, but I play one on Slashdot.
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.
;) No interface is without cruft, I suppose, though the Win32 api is cruftier than most.
But as another poster pointed out, exec() isn't any better
Redundance != choice!
Want to hear the voice of GOD? cat
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.
In the name of sticking up for someone with autism, f**k you! Prejudiced bastard.... that is unlawful and linuc for dumm
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).
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.
God made the natural numbers; all else is the work of man - Kronecker
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!
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.
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
Those are all library functions wrapping the same underlying system call (execve).
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.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'