I just read that Picasa will no longer be released for GNU/Linux. I won’t miss it because I have been using other applications but this is an example of the problems that M$ wilfully created by offering ever more complex APIs for that other OS. Their idea was to seduce developers into making software that is not portable. Apparently Google fell for that as they made Picasa available to GNU/Linux using Wine which is like playing a game where the goal-posts are mobile. Effort is wasted.

Instead of Picasa, I use lots of tools available on many GNU/Linux systems:

  • Imagemagick for quickly resizing/cropping images from the BASH prompt.
  • Gimp for the same with a GUI
  • Gallery for a searchable database of images
  • The normal file-system of GNU/Linux, and SSH to move files between systems

Those tools cost $0 and are available in Debian GNU/Linux via the APT package management tool. A few seconds work is all it takes to install the lot of them.
“apt-get update;apt-get install apache2-mpm-prefork mysql-server-5.1 imagemagick gimp ssh-client libapache2-mod-php5”

Use FLOSS. It’s the right way to do IT.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

29 Responses to Picasa

  1. oiaohm says:

    Phenom No chroot then you did not need compatibility mode wait you did. Guess what compatibility mode is a fancy chroot with a nice front end.

    Lack of front end on the Linux side you can complain about.

    Sorry My incompatibilities are not fairly tails.

    win32s is a emulation of 32 bit nt. So that is not going back to a 16 bit OS as such. In fact win32s runs a 32 bit kernel even on windows 3.1.

    Simple fact a A multimedia application that is truly designed to operate on a 16 bit OS will not run on 64 bit windows. Win32s does not run on 16 bit hardware and overrides large sections of the 16 bit core of windows 3.1.

    So your statement about 16 bit OS is false Phenom.

    32 bit OS with different kernel would be a valid claim operating on 64 bit kernel.

    Yet explain why under wine on 64 bit Linux I can run a true win16 application yet under 64 Windows you cannot Phenom. Yes I can still run true windows 3.1 16 bit OS mode applications.

    Windows 3.1 has two modes. One in 386 mode and one in 16 bit modes. Win32s only works in 386 mode with the 32 bit kernel.

    Most people are not aware Windows 3.1 is split personality all bar wine people who had to run test cases on the beast to locate the differences in the win16 mode between when 32 bit was enabled and not.

    Yes MS difference between versions is not new.

  2. Phenom says:

    Ohio, as usual you completely miss the point and go into some pseudo-technical discussion.

    A multimedia application, designed to work with an extension of a 16-bit OS, that Windows 3.1 actually is, runs perfectly well under the 64-bit incarnation of NT, which is a different OS in its core.

    No chroot, no “distribution thing”, no library archives, no recompiling sources. It just works. With all video and sound along.

    Now, spare me the fairy tales of Windows incompatibilities and Wine’s successes, that exist solely in that unique mind of yours. I can’t care less about that blabberings.

  3. Phenom says:

    Classical case of YouDontNeedThat(tm), Pogson.

  4. oiaohm says:

    Phenom really you show your foolishness.

    Win32s has relocation bits added. To a standard Win32 binary for NT. Win32 was design for NT not Windows 3.1.

    Yes Win32s is a back port from the NT line. so you skipped mentioning NT.

    Win16 is from the Windows 3.x 9x line.

    “It actually ran! However, it crashed after a some minutes. Then I ran it by setting the compatibility mode of the executable to Windows 95. Now it runs like charm.”

    True same thing happens to old Linux binaries as well. It runs then goes splat because some library or other is missing.

    Chroot is Linux world equal to a compatibly mode. Again this is a distribution thing.

    Complaining that the Linux compatibility mode is too hard for normal people to use is valid. Saying it don’t have the compatibility is wrong.

    Even so you were lucky there are a lot of win32s programs people come to wine and ask the wine project to port to windows to make work due to defects in Windows 7 support even using compatibility mode yet the application works platinum rated in wine ie perfect.

    Try some win16 binaries and see how far you get. Wine supports them still on 64 bit systems. Windows does not.

    Win32s it must have been full 32 bit. Because any Win32s thunking to Win16 fails under 64 bit windows. You were lucky.

    Even win32 binaries for 9x-me still can contain thunking to win16 and fail under windows 64 bit. There are a lot of program that don’t work any more under windows 64 bit.

    Linux 32 bit to 64 bit change is fairly seamless at kernel level. Distribution level there are a few issues with package management.

    You still don’t have a leg to stand on Phenom. You just got lucky.

    Linux support back to Linux 2.0 is not luck. All most all userspace binaries from Linux 2.0 on will run today on a modern-day Linux kernel. Exceptions come from the likes of firewall that have been changed completely and other direct kernel control applications that are basically obsolete by newer replacements.

    Think about it if Linux added a compatibility mode that you could click on a binary pick a distribution time for what Libraries to use it would perform massively better than what windows does. Yes that is what that compatibility mode is doing.

    Do users demand this so far no.

  5. That’s a rare issue in FLOSS unless an app disappears. Usually packages improve year over year so it makes little sense to run an ancient version. I did it once to run in 16MB but that was 15 year old hardware not 15 year old software that we were running. I used the machine as a thin client.

  6. Phenom says:

    Pogson, whould you please undig my post?

  7. Phenom says:

    Recompiling may require digging up old libraries but there are archives. All one has to do is keep the libraries and app originally ran with and you can run forever.

    In comparison to that, yesterday I purchased an old CD with Dr. Seuss’s ABC for my little daughter to study English. The version was old, it was actually based on Win32s (sic!) and required Windows 3.1, 95 or 98. Just think about it – Windows 3.1.

    I started it under Windows 7 64 bit. And you know what? It actually ran! However, it crashed after a some minutes. Then I ran it by setting the compatibility mode of the executable to Windows 95. Now it runs like charm.

    You have a most venerable application, designed to work on a shell of an OS, hardly even fully 32-bit. And it works on a completely different OS, 64 bit. No virtualization. No recompiling code. No digging around in archives of libraries. Just a setting two clicks away.

    I really “start to feel sorry for you, “flossies. You make your lives so hard.

  8. oiaohm says:


    “Is it possible to run 10-15 years old Linux software on the modern distributives? Yes, WinApi are not absolutely stable, but you can say absolutely the same thing about Linux”

    Problem is this is where people like you are so screwed. Yes it is possible to run 10+ year old software on Linux today. The first Linux Standard Base applications work just as well as when they were first made.

    The userspace interfaces don’t change that often. Documented stable interfaces functions never break under Linux.

    With that kernel version thing there is a flag to have the Linux kernel lie what kernel version it is to userspace on application by application base just like Windows.

    It will get simpler with multi arch and multi distribution work in the package management.

    The issue with old applications not running is not a Linux kernel or Linux design issue but a distribution one.

    Key thing most people are not aware is Linux kernel does not load dynamic binaries. This is done by a small static program called a loader.

    Linux standard base has its own loader for its versions. So it can load the right libraries for the application so is ABI stable started in 2000 and it worked ever since.

    Distrobutions use the same loader name for all versions even the same loader name as other distributions so resulting in no backwards compatibility. So you have to use a chroot to work around a defect from distribution package makers.

    Windows does depend at times on applications included version tag to run the right functions so application runs.

    Just because the Linux internal kernel space changes radically does not equal userspace doing the same thing. Linux Device.

    Go back one section http://www.xml.com/ldd/chapter/book/ch02.html#t7

    Notice doing it in userspace don’t talk about backwards or forwards compatibility crap. Because there is none. A driver done in userspace no matter how crappy still works today.

    GTK issue is solved by installing multi versions. Most distrobutions do. Microsoft also installs multi versions of particular libs. Also GTK contains test suite so you don’t see stable functions that have been stable for years magically break.

    ALSA problem is more particular drivers not providing particular features not the ABI changing.

    Sorry you have nothing to argue with here. iLia.

    Lets try to say Linux is as bad is not going to work because if it is present the test suite proven it. Guess what they don’t exist because the test suites prove the exact other way.

  9. iLia wrote, “Is it possible to run 10-15 years old Linux software on the modern distributives?”

    Certainly. I have done it. Since the source code and the original distro it ran on are available, one can just fire it up anywhere, even a virtual machine. Recompiling may require digging up old libraries but there are archives. All one has to do is keep the libraries and app originally ran with and you can run forever. Will all the bugs be gone? No.

  10. iLia says:

    And what about Linux APIs, you know ALSA and other sound subsystems, GTK they are also not so stable.

    Can you say that there is no problems with backward compatibility in Linux and in FLOSS?

    Is it possible to run 10-15 years old Linux software on the modern distributives? Yes, WinApi are not absolutely stable, but you can say absolutely the same thing about Linux:

    Linux Device Drivers

    The Linux kernel is a moving target — many things change over time as new features are developed. The interface that we have described in this chapter is that provided by the 2.4 kernel; if your code needs to work on older releases, you will need to take various steps to make that happen.

    This is the first of many “backward compatibility” sections in this book. At the end of each chapter we’ll cover the things that have changed since version 2.0 of the kernel, and what needs to be done to make your code portable.

    For starters, the KERNEL_VERSION macro was introduced in kernel 2.1.90. The sysdep.h header file contains a replacement for kernels that need it.

  11. Cute. I just used MySQL client or PHPMyAdmin to access the data. I did port some to Sugar CRM for mailings.

  12. oiaohm says:

    Robert Pogson I have got evil in cases of java and fixed windows paths before know cure.

    http://asm.ow2.org/index.html I wrote a little tool in this. Basically lets disassemble the complete program rebuild it with paths fixed.
    “C:\” embedded all over the application is basically swear and say that going to cost another 30 to 60 mins as computer reworks the code if it is a largish program

    Issue is not paths but JNI. Program uses a JNI that windows only then you are in hell.

    The html thing is in my processing scripts pile of tools as well. If you are in a hurry and need it up quite items like http://www.brain-dump.org/projects/ciopfs/ make the html issue and source code with same problem build.

    Linux can work around most things. Its just knowning how. But really we should not need to know how to rework a java program because someone was too lazy to code it right in the first place.

    Pure java programs are not a problem to me even if the coder was stupid with paths. Paths are changeable quite simply.

  13. Amen. I can give another example of usage that makes applications unportable, the file-system. In my province, schools send in their leadership/contact information to a central database. To encourage use, the schools are provided a local copy of the database for their purposes ( hiring staff, checking teaching experience, requesting forwarding students’ records when they change schools, etc.). The application uses MySQL and Java but is not portable… They have “C:\” embedded all over the application… Fortunately, the database can be extracted and used by schools with GNU/Linux but it takes some knowledge of MySQL because the app won’t run.

    In another case, a forestry association distributed really interesting stuff about forests to schools on CD. They used mixed-case filenames and inconsistent case for the same filename all over the CD in HTML files. I made a local copy, fixed the problem and sent the originator a copy.

    Folks creating software for that other OS who use M$’s “helpful” stuff are just digging themselves a hole. Folks who don’t climb out or avoid the hole will pay to use their PCs forever while GNU/Linux users optimize price/performance for their IT. To the trolls who claim that as long as they stay with M$ there is no problem, remember M$ keeps changing whatever they want to force you to buy yet another licence… Some migrations to GNU/Linux have been for that reason mostly, lock-in to a single supplier.

  14. oiaohm says:

    “The point of a test suite is to produce evidence that the product works as advertised. In the case of failure, a subsidiary requirement (all too rarely observed, in my experience) is that some sort of analysis should be provided to enable the relevant fixes to be made.”

    That is exactly what the wine test suite is designed todo. Conform where wine matches operating exactly like windows and confirm where it does not operate exactly like windows.

    It does not help that Windows is all over the shop.

    Out of the 12 test machines wine uses for windows 7 there is not a pair of matching errors perfectly. They are all over the shop. Yes there are common defects but they are mixed up.

    ernest something people don’t know wine started as a project to implement windows abi without defect as per standard MS released. But due to the reality of windows ABI being a mess wine had to accept in 1996 that from then on they would have todo bug for bug compatibility or not be able to run applications.

    Yes the test suite of wine makes the clean not a he said she said but a tested fact with know displayable problems. This is the science method. Person presents theory. You find something to test theory. A suitable test suite in this case. If theory was false test suite would prove it so.

    iLia you claim against Roberts Claim is not backed with data. My claim support Roberts Claim is backed with data. So you are not telling the truth basically iLia.

    –“M$ has APIs designed to make software unportable.”

    Name one, Robert.–

    That is in the court case against Microsoft over anti-trust in the USA. It also does not take very much looking. The order or arguments MS uses on it functions is the reverse to posix and os/2. This was intentional to break compatibility and its documented in a memo. This prevents using a #define x y in C to change the functions over.

    Basically almost all of win32/win64 abi contains this fact to be intentionally not portable.

    This claim also can be backed by existing documents of someone puts enough effort in.

  15. oiaohm says:

    ernest wine is beta/alpha software. So we know its buggy. This is why it has such a huge test-suite designed to test the windows api and ABI. But why its buggy is because it coping something that is buggy. This makes it a lot harder to know if you have implemented it right.

    Wine does bug for bug compadiblity. So tests are made to make sure wine function matches windows function.

    These tests are extracted by how real world applications interface with the ABI.

    ““Main summary for build d080774e75d8″ That at the top is the version of testsuite used.

    You don’t have to look far in fact to see the problems. Ok why on XP advapi32:security fail 7 times yet it does not fail once on any other version of windows. Note that is the same program being run on all from the testsuite.

    advapi32:service fails 14 times on windows 7 yet it don’t fail on vista or windows 8.

    Now if you go one step deeper into wine test system the mess gets even more interesting.


    This is just the tests run on Windows 7 with the wine testsuite. comctl32:listview is like a basic function. Yet it broken on some installs of Windows 7.

    Yes those red lines of failures should be the same all the way across if the ABI of windows 7 was stable. Since a failure could be testsuite defect so if the testsuite is defective it should be all the way across between tests.

    Windows is not the same version to version. Its not even the same install to install. This is what gives wine so much trouble implementing windows ABI.

    Because you can test a particular machine and say the function works that way but that machine turns out to be broken compared to what applications developers expect.

    In fact developing on windows I find wine testsuite highly useful in cases of people reporting odd ball problems. Its like do I use any functions wine testsuite tell me are unstable on that platform. Makes debuging thousands of times simpler.

    If you look closely at the wine testsuite results the unstablity of win32 and win64 becomes clear. It explains why X program from XP does not work on 7 and why X program from vista does not work on 7 as well. And it also explains why a program runs on one copy of windows 7 yet not on another.

    Testsuite is a brilliant install debugging tool.

  16. ernest says:

    “M$ has APIs designed to make software unportable.”

    Name one, Robert.

    And be very careful about picking it. After all, there’s that Oracle vs Google API war to consider.

    Just one. One. Name one.

  17. ernest says:

    In re iLia’s comments on test suites (as quoted in evidence by oiaohm in defence of both Wine and Mono).

    The point of a test suite is to produce evidence that the product works as advertised. In the case of failure, a subsidiary requirement (all too rarely observed, in my experience) is that some sort of analysis should be provided to enable the relevant fixes to be made.

    Now, let’s assume (I do not) that the test suites of either Wine or Mono are designed to do this.

    Wouldn’t it be worth publishing the results, so that the underlying software might be improved?

    I mean, this isn’t just a “he said, she said” playground game. Software doesn’t work like that.

    And for the record, I think that Mono is an excellent and standard-driven endeavour, and Wine is a total waste of time. But, either way. Publish, and do not damn.

  18. iLia says:

    but that product is tied to M$’s environment…

    So what? As long as they have ~90% market share, it is more than tolerable.

    …an unnatural monopoly

    Why Apple doesn’t allow other vendors to sell cheaper computers, smartphones and tablets with Apple’s OSs? Or maybe they simply don’t want to loose their “crazily” hight profit level?

    As M$’s share of IT continues to decline…

    And how long it will take? 10 years, 20 years?

    …more will see the light and adopt FLOSS

    No, they will not adopt FLOSS, they will rather stop using computers.

  19. M$ has APIs designed to make software unportable. Lack of portability is not “richness”. It’s defective design. Using M$’s APIs appears to some developers to be a shorter path to a finished product but that product is tied to M$’s environment, an unnatural monopoly. As M$’s share of IT continues to decline, more will see the light and adopt FLOSS. It’s the right way to do IT.

  20. Herr Blatt says:

    this is an example of the problems that M$ wilfully created by offering ever more complex APIs for that other OS

    Are you saying MS has richer APIs? You’re not exactly trashing MS with that “accusation”.

    Their idea was to seduce developers into making software that is not portable

    Um, that’s the business modell of every OS vendor. I am sure Tim Cook is losing sleep over all the iPhone-only apps.

  21. iLia says:

    Microsoft is guilty of poor quality control and it documented many times over

    It seams to me that that it is wine and Mono projects how have poor quality control.

    .net test-suites from mono and others against MS .net you also see the same inconsistency.

    Which test-suites? Please tell me! Oh, by the way .Net and Mono are not fully compatible, especially when it comes to Winforms. And Mono doesn’t implement all parts of .Net.

    And explain me how test-suites for one software can be used to test other?

    And please explain me how “Main summary for build d080774e75d8” of Wine can proof that windows is crappy?

  22. oiaohm says:

    iLia testcases back “There’s nothing homogeneous about that other OS.”

    For exact example about win32.

    NT4, 2000, XP,2003, Vista, 2008, Win7 and Win8 along the top is the wine test-suite being run on those versions of windows.

    Interesting right that NT4 2003 and 2008 don’t fail any tests completely. Seams that MS server products get better quality control than desktop products.

    Yes you see a little up and down even in the same version of windows.

    When you run .net test-suites from mono and others against MS .net you also see the same inconsistency. This is a direct result of Microsoft not having a proper test suite system their end.

    Microsoft is guilty of poor quality control and it documented many times over. iLia so Robert is perfectly fine to place that claim.

    Also remember wine test suite is based off how real world applications interact with windows.

    Yes the wine test suite proves wine still has a long way to go. Wine would be progressing quicker if it was not having to deal with particular versions of windows corner cases caused by Ms lack of quality control.

    Wine has to implement bug for bug compatibility.

  23. iLia says:

    There’s nothing homogeneous about that other OS.

    And what about Win32 and .Net?

  24. oiaohm says:

    Picasa if I had to pick a single application that replaces all its functionality then some it would be digikam. Really if digikam port worked on windows fully there would not be very much point to Picasa at all. Yes digikam can upload and downloads from to all the online storage Picasa can and more.

    Shotwell is gnome kind of equal but its lacking particular features Picasa has.

  25. No problem at all. Google does not lock people in so they can manage their images with any system they like.

  26. iLia questioning the use of SSH for sharing pictures wrote, “Using ssh for sharing pictures???”

    Well, yes. In our home we have multiple PCs and just a few people. The people move around so sharing pictures over the LAN is convenient, almost necessary. Digital cameras crank these things out by the thousands and they have to go somewhere but be viewed anywhere. sshfs works for us. SSH is very flexible and has many uses: managing multiple systems, file transfer, file sharing, making worm-holes for less-secure protocols like database, printing, X11 … It’s easier and better to use one protocol for everything. I did try to get “the little woman” to use a database for the pix but she is set in her ways.

  27. There’s nothing homogeneous about that other OS.

  28. iLia says:

    Mr. Pogson, please stop bashing Linux!

    Using ssh for sharing pictures??? Great!

    I have almost nothing to add! I feel myself so useless 🙂

    Their idea was to seduce developers into making software that is not portable.

    No their idea was to provide developers with a rich homogeneous platform and allow them develop wide range of complex applications. Windows was always very open to developers. That is why they prefer develop for Windows.

    Their idea was to seduce developers into making software that is not portable.

    No, this is Linux which make application porting extremely difficult.

    All these distributives use different versions of libraries, which sometimes are not backward compatible and they use different package formats. Don’t forget about configure/make files. All this make development and maintaining of linux software very difficult. When new version of a major linux distributive arrives, the developers must test their software to assure that it works properly with it. And such advents happen almost every month.

    Taking in consideration the tiny market share of linux, it is clear why almost no one cares to develop software for it.

    It is too difficult for small companies, so instead of investing time and resources in porting software to linux they prefer to improve its windows versions.

  29. Clarence Moon says:

    It would seem to me that Linux + Picasa fans, in following your advice to avoid lock-in, are suddenly faced with “lock-out”! Which do you think is more of a problem, Mr. Pogson?

Leave a Reply