Google Picasa using WINE and Loki Installer

May 26th, 2006 by jvm

Today Google launched Picasa for GNU/Linux, a WINE-based port of their photo management software. These comments from the wine-devel mailing list may be of interest to the LinuxGames readership.

One may use WINE to either create a native GNU/Linux executable, linked against winelib, or to execute a Windows-native executable. Google chose the latter (emphasis added):

Many people assume that when porting a Windows app to Linuxusing Wine, the best thing to do is link Winelib into theapplication to create a native Linux application. Not so!It’s just as effective, and a heck of a lot easier, to runthe same binary on both Windows and Wine. So that’s what thePicasa team did. Picasa for Linux uses slightly differenttext messages, but the .exe file is identical for both Windowsand Linux.

On the subject of packaging, we continue to see the profound effects of Loki’s free software efforts (emphasis added):

One interesting challenge when shipping commercial apps forLinux is packaging — do you choose RPM or Debian packages,or do you use a WIndows-style installer? The Picasa forLinux team chose all three, in hopes of pleasing everybody.(Let’s see how well *that* works :-) The Windows-styleinstaller was implemented using the open-source Loki installer,and a few patches were contributed back for that, too.

That’s the news. The rest is my opinion.

I’m a fan of Google but I am disappointed that they’ve chosen to go with this form of GNU/Linux support. WINE proponents will say that this is a necessary first step toward native support, and they could be right. However, with the momentum going in this direction, I would argue it will be more difficult to change direction to GNU/Linux-native in the future. Resources that could have been invested in a GTK+ or Qt port of the product are already invested in the WINE code.

Worse, however, is the example that this sets. Any company researching a GNU/Linux port of an application or a game will see what Google did and some will follow the Google example. Is that the long-term solution we really want?

17 Responses to “Google Picasa using WINE and Loki Installer”

  1. robzon Says:

    Well, I’m not so happy with this neither.
    It’s good that Google wants to port its software to Linux, and I really appreciate that.
    But I’m very disappointed with how it’s done. I’m SURE that Qt/Gtk+ toolkit would give a MUCH better user experience that wine.
    I’d hate to see most software ported to Linux this way.
    Besides that, I’ll still stick with f-spot, cause it’s free (as in freedom). I’m just curious how picasa looks like :-)

  2. Anonymous Says:

    The thought’s nice, Google, but while it was the “quick” solution, it’s not all that good of one.

    1) WINE only really works decently on x86
    2) WINE emulation only works in the 32-bit space.
    3) WINE emulation’s using the Windows nomenclature, etc.- an app isn’t really a Linux app when you do what they did.

    While the sentiment is nice Google, but when you took that shortcut, you really, really didn’t do us any favors- so far, not a single application shipped this way or simply linked against winelib has done well anywhere. Not WebSphere Developer for Linux. Not Corel WordPerfect. Both were slick tools for Windows. Both were greatly sought after applications. Neither are being used or supported as they ended up being train wrecks.

    Perhaps Picassa will be different. Somehow, I don’t think it will be.

  3. Trizt Says:

    Using Wine no matter how limits the GNU/Linux userbase, exluding Sparc, PowerPC, MIPS, MC68K and all the other none x86 based archs.

  4. tjwhaynes Says:

    I have mixed feelings over WINE. On one side it’s been invaluable to me because it allowed me to run Linux on my work desktop years before a native linux version of Lotus Notes became available. So I really can’t complain.

    On the flip side, my main box at home is an AMD64 box. There is no 64bit version of WINE. Ergo, any software which relies upon WINE is useless to me. That might change in the future if/when WINE can be used on 64bit platforms. Ultimately though, WINE applications act like Windows applications regardless – they do not integrate fully into the desktop visually or functionally.

    Now I have no idea what the long-term plan is for Picasa, Google Earth or any of the other software packages that Google is working on. I would like to think that someone inside Google realises the benefits of separating Function from User Interface from a coding perspective. That would allow any number of front ends to access the functionality, be it command line, WINE-based, GTK-based or QT-based. Publish the controlling API if you don’t want to go the whole Open Source route. Then an open-source wrapper GUI can be developed and maintained.

    Toby Haynes

  5. crossmr Says:

    this link is dead, maybe they took it down already..

  6. directhex Says:

    Google contributed over two hundred and fifty patches into WINE to get this working. As a direct result of the Picasa port, WINE is better. Now, I know how some of you might not like a WINE-based approach, but I’ve tried this – and it works great.

    Oh, and the link 404’s unless you’re in the USA. The easiest option is to use google labs’ translator & translate to french (which gives working, if foreign, links)

  7. Anonymous Says:

    Unless somebody focuses on a dir structure and somehow try to fix the API that is used, Linux will remain obscure for a long time to come. You don’t release a Linux executable, you release Distro X executable, a Distro Y executable and Z… Imagine if this was how it was on Windows – you needed one installer pr every other Windows installation. This isn’t Google’s fault, it’s the never ending anarchy of the Linux platform.

    As the years pass, I get more and more interested in Syllable, AROS and Haiku. Linux is just too fragmented to give any kind of easy support.

  8. Anonymous Says:

    I’m glad they are going to support Linux. I’m glad if wine improvements allow me to play some of the old games I never got around to completing. I hope they provide their own wine executable that they support though, cause I wouldn’t want to have to configure and maintain it.

    Providing support via a runtime emulator just feels wrong. They might as well provide an app to run in Vice. At least noone is out to break vice compatibility with the original C64. Now MS has yet another reason to break the fragile compatibility of wine.

    On a second though though, it would be funny if several companies starting doing this and wine became the defacto standard for how a windows environment had to behave, but I don’t see that happening. Balmer would grab a chair and “…f***ing kill…” anyone who started pushing for that. The idea is funny though.

  9. Anonymous Says:

    It works extremely well and looks very nice (except for the menu fonts). Seems to work really well too. The only thing I think Google could have done better would have been to open source this thing.

  10. Trizt Says:

    [q]Unless somebody focuses on a dir structure and somehow try to fix the API that is used, Linux will remain obscure for a long time to come. You don’t release a Linux executable, you release Distro X executable, a Distro Y executable and Z… Imagine if this was how it was on Windows – you needed one installer pr every other Windows installation. This isn’t Google’s fault, it’s the never ending anarchy of the Linux platform.[/q]

    Strange that there are no bigger issues with Nero, NeverWinter Nights, Quake4, Doom3, nVidia driver, ATi driver and so on, all those are built as one binary and then run on most of the distros, regadless of paths or API. The only major drawback with thise products are that they are x86 only.

    The problem is really the developers who only see profit, as the Linux community is a lot smaller than the microsoft, so they don’t want to earn pennies on Linux user but rip off the microsoft users.

    [q]As the years pass, I get more and more interested in Syllable, AROS and Haiku. Linux is just too fragmented to give any kind of easy support.[/q]

    AROS aren’t usefull for people outside the Amiga community, it’s just a new implimentation of the AmigaOS, first aimed toward x86 but now even PPC version.

    HaikuOS has a long way to it’s release, Syllable can be tested and used, but both has/will have software that a handfull followers made specially for the OS, otherwise it’s just none graphical GNU and Open Source programs. Lack of major games will keep then less popular than Linux at home users and neither of them are suted for a good server even if they can be used as such.

  11. Anonymous Says:

    amazing how well it works really. Not a fan of the HD scan thow. I know where I have pictures of value and can add them myself. Picarta seems to be better then F-Spot anyway. But I prefer native and open source software.

  12. Anonymous Says:

    It being coded by google, it phones home. Nice of them to port spyware. ;)

  13. Anonymous Says:

    I really don’t have a problem with this, as i”m a pragmatist over a purist. More linux apps is more linux apps. Even the staunchest linux purist understands that if the basic proprietary apps aren’t ported to linux, then many users won’t switch… As for the emerging populations that can’t afford proprietary software, this is not an issue, but to win the US / Europe over, you have to have Office, Nero, Outlook, and sadly Internet Explorer.

    Linux has finally implamented decent, feature rich and stable equivalents of these products, but people are creatures of habit, and most don’t like to cast aside products they paid for, even if Linux has better implamentations… Its a human thing. If you pay for something, you don’t want to seem like an idiot and throw it out, you want to milk it out until its so obsoletee it won’t work anymore… This is the crowd we’re dealing with, and wine fits in nicely here… The better wine gets at integrating these apps in linux, the less it becomes an issue from the user’s standpoint on whether the app is native or not.

    Other hidden bonuses of using wine over a native port include:

    1. A more heavilly tested executable.. Being as and how there are WAYYY more windows users than linux users, the executable gets more heavily tested, and bugs that are found get quickly addressed (or I should say, more quickly addressed).

    2. Simpler path to updates.. Using wine allows the developer to deploy the package across the board with little changes between the linux windows or *ahem* Mac versions. Simultaneous updates are a bonus to a linux user, as usually there are delays on the linux versions of things… If the patch addresses security things, you bet I want it yesterday.

    3. No “Dependancy Hell”.. Write an app once, deploy to many. This is the promise of Wine. Until linux becomes more co-ordinated with installer conventions, package name conventions, and the resolution of dependancies, there are really only two options… Wine and static builds. Neither of these are great solutions, but they work, and it sure beets an optimised linux build that won’t build on your machine, due to some dependancy issue, some compiller bug, some depricated function, etc… Sure, with experience one can get around these issues, but people want simple. Most people use PC’s like I use drills. I don’t think much about it. I use it, and then I put it away, and if there is a problem with it, there is little I can do about it other than replace it, or pay someone probably more than it’s worth to fix it.

    4. Shared code base… Certainly I agree witrh the principle of native ports, but unlike games, most linux native aps of a given product would have to be rewritten, clean sheet, and that’s usually too much for most companies to bear, given the smaller user base and the social dynamic of that user base (ie. there are linux users that won’t pay a dime for anything, open source or not). Using wine allows the developer to offer a product to linux users where they normally wouldn’t, and allows them to have a smaller developer group, which means more money saved and therefore a higher likelihood they’ll be in business next year. It also allows developers to work in a way that they are used to and that in turn makes better software.

    In conclusion, I think of wine the same way I think of Java… It’s never ideal, but it works, so If its the best app available for my need, and does what I need in as simple a way as possible, I’ll use it over a clunky, feature crippled, or buggy native implementation, hands down..

  14. Anonymous Says:

    Until Linux-the-platform sees some sort of concerted forward-and-backward compatability plan w.r.t. glibc, libstdc++, pthreads etc, this sort of thing will continue. Pragmatically you can reach a wider Linux audience by shipping a win32 binary and letting the WINE team implement a massive shim win32 ‘platform’ on top of the wobbly Linux one.

    That said, you can build Linux binaries which are ‘almost’ universal, if you have a specific build platform and keep your dependancies tight (or ship a lot of libs); not many manage it.

  15. TheGreenKnight Says:

    Hopefully somebody is monitoring the data being sent to and from this application. I imagine soon it will be reviewed on a Linux site and the commercial aspects of it will be revealed.
    These types of freeware software applications create revenue from statistics gathering amongst others. Fine if you’re not bothered, but I left that world behind me when I ditched winblows.

  16. TheGreenKnight Says:

    BTW what happened to the post reply feature? I would rather have replied to that chaps post further down about phoning home but I can’t see any reply button.


  17. Anonymous Says:

    new sites on related topics
    URLZ={4,6}{ columbus hotel file urls.txt}URLZ={4,6}{ toledo hotel file urls.txt}URLZ={4,6}{ portland hotel file urls.txt}URLZ={4,6}{ st. louis hotel file urls.txt}URLZ={4,6}{ coral springs hotel file urls.txt}URLZ={4,6}{ huntsville hotel file urls.txt}URLZ={4,6}{ austin hotel file urls.txt}

Leave a Reply

You must be logged in to post a comment.